Lightweight display manager for xfce?

[Auke Kok]

On 05/28/2011 12:26 PM, Yves-Alexis Perez wrote:
> On sam., 2011-05-28 at 12:04 -0700, Auke Kok wrote:
>> On 05/28/2011 12:56 AM, Yves-Alexis Perez wrote:
>>> On ven., 2011-05-27 at 21:37 -0700, Auke Kok wrote:
>>>> On 05/26/2011 11:07 PM, Yves-Alexis Perez wrote:
>>>>    >   Note that I've quickly tried uxlaunch on my Debian. It might be related
>>>>    >   to some integration lacking, but it failed to use consolekit properly.
>>>>    >
>>>>    >   When running directly startxfce4 or xfce4-session, it won't start the
>>>>    >   consolekit daemons.
>>>>
>>>> console-kit-daemon needs to be running before uxlaunch starts. It's up
>>>> to the ConsoleKit packager to assure it's running before uxlaunch starts.
>>>>
>>>> of course, systemd should start it on-demand for you if you're lucky
>>>> enough to use that.
>>>
>>> Well, I don't know about systemd (and frankly the first impression I
>>> have is “scary”). I'm not too sure why consolekit would have to be run
>>> before uxlaunch though. uxlaunch by itself doesn't need any permissions
>>> so only stuff launched by it require it. Or am I mistaken?
>>
>> we're using a minimal design - console-kit-daemon should really be run
>> independently of a X11 session so it can manage more than just 1 session
>>    (e.g. ssh logins, vc/? logons), so it doesn't make much sense to
>> enabled it in uxlaunch.
>
> I find that weird for a daemon which is supposed to handle stuff for one
> user only :)

it's not meant for one user, and similarly, it talks over the system bus 
instead of over the session bus.

hence, it should be a global daemon, not a per-user service.

>> Perhaps this is a bit confusing, but uxlaunch is really meant as a "do
>> everything as the user" type application. While it is started as root,
>> it immediately drops privileges before it actually does anything
>> significant.
>>
>>> Right now, if consolekit is launched by uxlaunch before startxfce4, the
>>> issue is the same as with slim (before patch) and xdm, the session is
>>> marked as non local.
>>
>> console-kit-daemon needs to be started as root before uxlaunch runs, and
>> you shouldn't use startxfce4, but uxlaunch should run `xfce4-session`
>> instead as session program.
>
> xfce4-session by itself is usually not enough, it lacks stuff which is
> not yet run by xdg/autostart (xscreensaver, xrdb stuff etc.)

do you really need xrdb? if so, please stop using uxlaunch altogether, I 
really do not intend for uxlaunch to work with legacy X11-isms and 
honestly, the few applications out there that still need it should be 
rewritten or replaced at this point.

Perhaps that's harsh, but, progress means you have to remove 
compatibility at one point. Otherwise you're stuck piling old code on 
top of old code.

you can obviously add xscreensaver to xfce4-session or just a normal 
autostart desktop file, there's nothing stopping you from doing that.

>> I'm figuring this is what messes up: startxfce4 has a ton of shell code
>> that starts a new consolekit seat, and so the two that are now created
>> conflict, or the current one is modified wrongly.
>
> Nop, startxfce4 works just fine, if there's already a consolekit daemon
> it doesn't do anything, that's all. Same thing with dbus, ssh-agent etc.

that stuff should really be taken care of before your session even 
starts, and that's why uxlaunch does all that (including ssh-agent), and 
similarly, gdm does it for you.

I'm getting the idea that debian just needs to add console-kit-daemon as 
in init.d type global service and it should all work...

> While I do agree that starting those shouldn't be done in startxfce4
> (because adding support for all that stuff there is painful and a never
> ending task), it just works fine with the current state of things.

well, it's actually *bad* that xfce4 ships with this, since, it makes 
the xfce4 desktop dependent on things like `startxfce4` in the first 
place, while we should really build on tools like gdm and uxlaunch to 
start *any* desktop session in the right way.

Look at the mailinglist and see how many people need to do weird things 
to get their xfce4 session starting properly. That's really bad.

>> If someone has some time to debug/document this for debian, I can maybe
>> work with them to figure it out how to integrate on debian in the
>> "intended" way.
>
> The “default” config file advertises to use xfce4-session, I manually
> changed it to do the right thing, which is Xsession and startxfce4.

which is not really the right thing, but a workaround for the above 
console-kit-daemon issue...

>> the uxlaunch.log file should give a ton of hints too - feel free to send
>> me that+stdout.
>
> For now I've just removed it and switched back to gdm (2), since I need
> the box to work, but when I have time I'll give it another chance.

cool, thanks. I'll be happy to spend some time on this in the weekends 
if that helps.

Auke