I really need to show a modal dialog window for some users. I've checked both the kdialog and notify-send commands, I've seen nothing about showing dialogs as modal, though.

Is there a standard way to do this, or any tip on how to achieve this, or at least the modal effect?

Thanks.

If I understand this correctly, you want to create a modal dialog for a window which isn't yours? I don't think that's a supported use case, in which situation does this make sense?

Otherwise, if you want to show the dialog from within your application, just use exec() instead of show().

What I'm trying to do is just open up a modal window on a user login. The user logs in, I run a script which makes some tests for his login, and if the test is positive, I want to show a dialog window that would be modal. I don't want to do this using my own application, just call some command that would show a modal window, just like "kdialog ..." does, but in modal.

"modal" is always relative to a parent window (i.e. the window the dialog prevents you from using). What would be the parent window in this case?

I guess that the KDE desktop itself? My aim is to make that the user cannot do anything (not clicking on the desktop, on any icon, and not even clicking on the menu) without accepting that Dialog window.

That'd be plasma-desktop then. I don't think what you want to do is reasonably possible without writing a plasma plugin or patch (sorry, I'm not very informed about plasma's internals).

One hack which comes to mind is to pkill -STOP plasma-desktop, then show the dialog, then pkill -CONT plasma-desktop. But don't tell anyone I said that.

In case you're looking for a global modal dialog (all gnome 3 modal dialogs are afaiu):
The concept does not exist in NETWM nor in KWin and there's absolutely no intention to add it - we do not stall the users workflow.
*No* client is that important.

Modality is meant to control workflow within an application (ie. because you should not continue to edit before done opening a document etc.) but there's no valid reason to enforce dealing with one application before all others (except for malicious reasons, scareware etc.)

Do you mind explaining why you believe it's imporant to stall the workflow (in general or actually even just the desktop) with your test completion dialog?
You can simply set it "keep above", if you want to ensure the user sees it.

(Notice that it's possible to make kdialog modal for the desktop and if you convince me that this is actually reasonable, I'm gonna tell you how

Ok, here it goes

My KDE installation is not conventional at all, I'm using KDE in a Thin-Client infrastructure (where the recommended environment is Gnome, but still I preferred KDE because its quite more versatile IMO to make a kiosk environment rather than Gnome). Each logging in client "forks" one KDE environment for their use on a central server.

As far as a client logs in on one of the clients, everything works smoothly, I don't have the intention nor the need to show a modal window to block everything. I know how important is the choice of the user and responsiveness of any application nowadays. However, if a naughty user wants to login on two different clients at the same time, there's where the problem begins, because due to our Thin-Client infrastructure design, processes are associated to the user's unix ID (we're using LDAP here). So, when this happens, when a user opens up an internet browser on the second client, effectively it's opened on the first of them, probably because the Thin Client infrastructure cannot differentiate which session is the actual one that issued the command, so it will assign the process to the first of them. This behavior cannot be changed because as I said, the unique identifier for any process is the user's unix ID.

This makes for us unfeasible to allow the same user log in onto two different clients at the same time, and that's why I need that blocking Dialog window. As I cannot control otherwise that a user has already started a session, my idea is allowing them log in with the second session too, then we'd use one of the Thin Client server's command and see how many times the user logged in. When it's more than once, I want to popup a blocking dialog telling them "Hey, you're already logged in for once! You can have just one session at a time!". So when the user accepts that dialog, I'd just log off the second session via the "qdbus org.kde.ksmserver /KSMServer logout 0 0 0" command. I could do that directly, but I think it will be less confusing for users knowing why they were actually forced to log off from the second session.

scummos' idea seems quite interesting, but in that case I'll need to know which of the two 'plasma-desktop' processes is actually the one I need to close - however, it's worth trying if there's not another way.

Thanks!

1st off:
If you're using KDM (or can figure the supported hooks for your DM), i'd suggest to block the user before loading the session, because that's faster and won't get you into trouble (KDE heavily relies on dbus and dbus is not really display aware, so two KDE sessions for the same user will end up being a problem anyway)

For KDM, /usr/share/config/kdm/ contains the interesting scripts - notably Xsession should be interesting and allow you to launch nothing but a naked X11 server with a dialog, that the user is allowed to close.
(Ideally, use one that is not tied to a DE by it's libs - I'm not sure whether kdialog will launch kdeinit and shamelessly advertise https://github.com/luebking/qarma


Back on topic:
To ensure that a user cannot interact with the system in any other way, you'd have to grab input, what's not possible with kdialog (nor any tool i'm aware of to pass exclusive input to a particular client)
You can create a dialog modal for the desktop:

Code: Select all

kdialog --attach <WId> --msgbox 'Get lost!'

where "WId" would be the WId of the desktop window - which you'll likely have to dig for with xwinfo and xprop:

Code: Select all

for WID in `xwininfo -root -tree | sed '/^ *0x/!d; s/^ *\(0x[^ ]*\) .*/\1/g'`; do
   if [[ "`xprop -id $WID _NET_WM_WINDOW_TYPE`" == *TYPE_DESKTOP* ]]; then
      echo $WID
      break
   fi
done


Please notice that this dialog will block the desktop, but not eg. krunner - the user can still Alt+F2 and launch random commands.

Thank you so much for the trick. We're enforced to use GDM here (yes, I know... ), I'll try to find out a way to block the second login but in case I can't, I'll use the way you described.

Thank you both!

Ah, good to know this works, that's a better solution than what I suggested

There seems to be /etc/gdm/Xsession which looks promising.

Because users will be able to cheat around that "modal" dialog and since starting two KDE sessions for the same user will run you into dbus trouble anyway, I'd strongly recommend to look into that solution (also it will cover any session the user might attempt to start)