Re: GDM login to a JHBuild session

[David Zeuthen <david fubar dk>]

On Tue, 2007-10-02 at 15:12 -0500, Brian Cameron wrote:
> Owen:
> 
> The GDM/KDM standard for using /usr/share/xsessions/*.desktop files is
> documented in the GDM documentation here:
> 
>    http://www.gnome.org/projects/gdm/docs/2.20/configuration.html
> 
> We can extend the .desktop file further if this makes it possible to
> do useful things.  However, if we are going to ask all distros to
> change the way they start dbus-launch to support DISABLE_DBUS_LAUNCH,
> then perhaps we should rethink how we start D-Bus.  Perhaps starting
> this at Xsession time isn't the right place?  Perhaps we should
> always start dbus-launch in the /usr/share/xsession/*.desktop files
> as needed?  Or perhaps it should be managed more directly by
> gnome-session itself rather than needing the login program/process
> to be aware of D-Bus?

In passing, this would also help to fix the problem we have with where
multiple desktop environments provides a .service file each for
org.freedesktop.FooBar. For example, if running under GNOME I'd like to
see gnome-foobar started and if running under KDE I'd like to see
kfoobar started [1]. However if gnome-foobar is not installed I want
kfoobar started and vice versa; it really doesn't matter much; both
provide equivalent functionality since they implement the same
service/interface.

Not wanting to get too technical however one way around this is to
specify multiple services directories e.g. 

 /usr/share/dbus-1/services.gnome
 /usr/share/dbus-1/services.kde
 /usr/share/dbus-1/services

and if I'm running in GNOME I get services.gnome:services.kde:services,
if I'm running in KDE I get services.kde:services.gnome:services. One
way to achieve this is to munge XDG_DATA_DIRS. Another option would be
to let gnome-session poke the bus and tell it to rearrange the order of
the service dirs (potentially racy). Or we could let the DM (e.g. GDM
and KDM) figure it out if we decide not to change things.

Either way, I think this is something we need to fix. Maybe this belongs
on the D-Bus list though.

     David

[1] : A concrete example is PolicyKit; the way it works right now is
that desktop apps can call into org.gnome.PolicyKit on the session bus
to request that the user authenticate in order to gain a privilege. This
service is activated on demand and goes away after 30 secs of
inactivity. Ideally, I'd like to tell application authors to call into
org.freedesktop.PolicyKit and then the appropriate GNOME or KDE daemon
is started to handle this. E.g. then the user gets the native desktop UI
that he expects.