[Xfce4-commits] <xfce4-session:master> Reuse existing ConsoleKit sessions (bug #6685).

[Yves-Alexis Perez]

On 20/09/2010 08:34, Auke Kok wrote:
> people still make .xsession? wow... :)

As I already told you, yes, it's used by default in Debian (and
derivatives) and it works perfectly. How, and it's desktop-independant
too, and works pretty fine with *dm or startx (as long as you don't mess
with it and try to execute something else than init).
> 
>>> I'm not 100% sure here but this is what I think about the situation:
>>>
>>> Before ConsoleKit, there was no "real" concept of sessions in the
>>> desktop world. There was communication between processes via ICE and of
>>> course there was basic session management based on X11 (a desktop
>>> environment may only run as long as the X server is up for instance) and
>>> in Xfce we had a dedicated D-Bus API for handling session management in
>>> client applications. The only session management of importance was our
>>> own, initiated by xfce4-session and valid only as long as xfce4-session
>>> was running. That's why startxfce4 could be used the same way in all
>>> situations.
>>
>> To be really fair, no. Dbus, ssh-agent etc. already needed to be started
>> *before* the session.
> 
> This is the concept we've implemented in uxlaunch and I strongly agree
> with this. On top of that, it's also what Gdm does... Deviating from
> this doesn't make much sense - it's just the better place.

Hmh, I didn't know about gdm doing that (the last gdm I use is gdm 2.20
or so). Wrt. uxlaunch, can it do a login manager role or is it only
useful in a single user world, doing the X startup and DE loading as
part of the boot process?
> 
>>> Yves-Alexis explained how it is supposed to be done in Debian. Now I
>>> wonder how other distributions handle this situation? What about
>>> Fedora, Arch etc.? We need to figure out if there is a standard way, so
>>> we can teach the "manual people" how to do it right.
>>
>> I think we need input from consolekit people on those platforms, too.
>> Imho the startup should be done by consolekit itself (which knows better
>> than us how to do it), but the DE should somehow figure out how to be
>> sure it's correctly started too (since it's a core functionality). I
>> heard there was some Xinitrc.d where scripts could be put, but I don't
>> think it behaves the same way as Xsession.d, which is not upstream for
>> unknown reasons.
> 
> well, I'd really try and not tell people to use either Xsession or
> xinitrc.d stuff. Nobody knows how it works, distro support is probably
> sparse, and on top of that any alternative to gdm should get this
> reasonably right, just like I'm trying to do with uxlaunch...

But that's the point, we don't really have any alternative to gdm, and
we don't really have the ressources to build one :) (well, I still
didn't have time to test lightdm). And anyway that still means there's a
need for some sort of standard about what to start and when as part as
the DE loading process, to create the session. Autostart is nice but
might happen too late in the process (I'm aware of the env var sharing
by the gnome-session stuff, but I'm not too sure it's enough for general
case, and it's not (yet) a standard anyway). Xsession.d is really nice
for that because it's just a bunch of shell scripts one package can put
at the correct place. But it's nowhere standard either.

I'm not sure what uxlaunch uses, but I guess it's yet another system?
Does anybody know how KDE does its stuff?

Cheers,
-- 
Yves-Alexis