Lightweight display manager for xfce?

[Yves-Alexis Perez]

On sam., 2011-05-28 at 16:15 -0700, Auke Kok wrote:

> > 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.

I don't really know how it should be started then. Right now, the config
file contains the username which needs it to be started as. How can it
handle starting for multiple users?
> 

> > 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.

Xfce does. And it's not the only one, XRessources, however old they are,
are still used by quite some tools. My current is:

*customization:	-color
XLock*background:	black
XLock*dpmsforce:	on
XLock*dpmsoff:	1
XLock*dpmsstandby:	0
XLock*dpmssuspend:	0
XLock*font:	fixed
XLock*foreground:	white
XLock*logoutButton:	-1
XLock*mode:	blank
XLock*planfont:	fixed
XLock*resetsaver:	0
XLock*timeelapsed:	1
Xcursor.size:	21
Xcursor.theme:	default
Xcursor.theme_core:	true
Xft.antialias:	1
Xft.hinting:	1
Xft.hintstyle:	hintfull
Xft.rgba:	rgb

So besides XLock which is specific for me (I prefer that pile of crap to
the others piles of crap), Xft and Xcursor still are used (and useful).

> 
> 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.

Yeah. Though breaking stuff that work for new shiny stuff but with
reduced functionality is starting to piss me a little. Not really for
uxlaunch, but the whole desktop evolution recently looks really like
that: the hal stuff, the various *kit, etc. We have regression in 4.8
because of that kind of things, because some stuff were dropped before
having a complete featureset. And this is only the Linux state,
compatibility has been trashed in a lot of cases.
> 
> you can obviously add xscreensaver to xfce4-session or just a normal 
> autostart desktop file, there's nothing stopping you from doing that.

Sure, but right now noone ships a xscreensaver.desktop.
> 
> >> 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.

No, gdm (2 at least) doesn't. And I disagree, there's no point in
starting the various agents before the session is started, and I really
prefer it's not.
> 
> 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...

Well, this is already started and it's not the point. What I'm speaking
of are the user-specific stuff (either ck-launch-session or support
inside the display manager, which iirc is supposed to be present in
uxlaunch but clearly failed in my case).
> 
> > 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.

Yes, and if you look at those threads you'll see people help. But not
shipping those means breaking current setups for people, and people
usually don't like regression. gdm is not really an option (gdm2 was
using gconf, gdm3 it's even worth). uxlaunch might (for people not doing
multi-user stuff though) but some people might still want to authentify
themselves before their desktop appear.

So yeah, as you said, uxlaunch is highly specific and can make
assomptions which are not valid in the general case. We (both Xfce and
Debian, and other distributions and os too) need (and want) to support
those cases.
> 
> >> 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...

As said above, not only.

Regards,
-- 
Yves-Alexis
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: This is a digitally signed message part
URL: <http://mail.xfce.org/pipermail/xfce/attachments/20110529/45659a6d/attachment.pgp>