System D-BUS and $DISPLAY

[Havoc Pennington]

On Tue, 2004-06-29 at 09:30, Johan Hedberg wrote:
> Is there any "good" current solution for telling a GUI application
> activated through the system D-BUS which $DISPLAY it should use?

Hmm, yes, that isn't how I've envisioned it working. In fact D-BUS was
in many ways invented as a way to avoid doing this ;-) The
bluetooth/hotplug stuff can already launch a GUI app from the script
hooks the kernel offers so if the plan was to launch GUI apps D-BUS
isn't even needed.

Keep in mind that if you start a GUI app as root and connect it to a
user display, the user can almost certainly in some way crack the app
and get root. GUI toolkits are not secure.

But systemwide services spawned by the daemon will be running as user
"dbus" anyhow (a nobody user) - which makes systemwide activation
near-useless, the idea is more that the initscripts system will be used
to start system services and they will then connect themselves to dbus.
At least for now, though you can imagine an initscripts replacement
based on D-BUS such as http://www.gnome.org/~seth/blog/2003/Sep/27 or
whatever.

> There was recently a discussion[1] on the bluez-devel mailing list about
> how this should be handled with the bluetooth pin-code dialog. The
> conclusion was that the best way currently is not to use activation at
> all, but to have the application running all the time in the background.

Exactly, the basic way the system bus is intended to be used is:
 - the system broadcasts some minimal information as a signal, 
   such as "device plugged in" or whatever
 - user desktop sessions respond to that signal by sending 
   information back to the system or taking some other action
 - (note plural sessions, the system has to be designed to handle 
   multiple sessions responding)

So for bluetooth the system says "I need a PIN!" and the user sessions
open a dialog to ask for one. David Zeuthen's HAL talk at GUADEC
yesterday (which is not at http://2004.guadec.org/wiki/DayTwo but maybe
will be later) discussed a "device manager" per-session daemon that
would do this kind of thing.

Havoc