autostart spec updates/extensions

[Lubos Lunak]

On Tuesday 17 October 2006 23:04, Dan Winship wrote:
> Lubos Lunak wrote:
> > On Sunday 08 October 2006 23:26, Dan Winship wrote:
> >> So that would yield a 5-phase system: SETUP, WINDOWMANAGER, PANELS,
> >> DESKTOP, and APPLICATIONS. Or something.
> >
> >  Or something. Except that you again get conflicts with XSMP. For
> > example, the window manager is actually session restored.
>
> Right. Rather than starting XSMP apps in one place and autostart apps in
> another (as both GNOME and KDE do currently) ,

 Not really. In KDE it's ultimately ksmserver who controls both of this.

> you'd have to merge the two lists of apps into one, sorted by
> phase/priority.

 I don't think it really matters. Except for the WM, it doesn't matter when 
session saved apps are restored.

> Alternatively, we could just not standardize this, and say that
> "portable" autostart files will always be started "late" (ie, in the
> APPLICATIONS phase in the model above). This is good enough for 90% of
> apps, although there are cases like compiz, where it would be nice if
> they could ship a single .desktop file that the user would copy to his
> autostart dir, that would cause it to start up early in the login
> sequence, regardless of what desktop you're using.

 I don't think launching a WM using autostart is a good idea (like e.g. some 
people suggesting to use one with "compiz --replace" in KDE). WM needs a 
special handling during startup.

> >>>> 7. XSMP
> >>
> >> Yes, that was the sort of thing I was imagining. Just wasn't sure if it
> >> would make sense to have it as part of the autostart spec.
> >
> >  The autostart spec should first define its relation to XSMP. Which usage
> > cases for autostart do you see besides initializing/launching desktop
> > components? And of course, hacked in manual session management in apps
> > that looks a lot like what XSMP should do?
>
> As Waldo said, this is probably most useful for desktop daemons (eg,
> beagled)

 Ok. They don't use XSMP at all and should be simple.

> and systray things (eg, NetworkManager applet).

 Systray and applets are two different things, the latter one being very 
simple because that's part of the panel and as such it shouldn't need 
autostart or XSMP either.

 As for systray (ok, I clearly admit I hate systray), I don't know about 
GNOME, but in KDE that's a mess. Some are session started, some are just a 
workaround for "minimizing" apps, some are launched manually by "something" 
(e.g. the keyboard layout switcher), some do their own manual session saving 
using autostart (sometimes with really absurd result, e.g. in order to get 
Klipper back, one has to start it, quit it and say that it should be started 
next time - otherwise it just doesn't work).

> In the gnome-session rewrite, my plan was to blur the line between XSMP
> and autostart, by saving the XSMP session state as autostart files. So
> dragging a launcher to ~/.config/autostart would be the same as saving a
> session where that app had registered itself with SmRestartAnyway.
> Basically autostart would be the underlying mechanism, and XSMP would
> just be an interface to autostart (and a way to get additional
> non-autostart behavior like asking to be automatically restarted if you
> crash). More details at
> http://mail.gnome.org/archives/desktop-devel-list/2006-September/msg00084.h
>tml (although ignore the bit about setting environment variables, since I've
> decided that there are better ways to deal with that). I was thinking of
> this as "GNOME's particular way of implementing the autostart spec",

 I think that should stay that way, unless there are good reasons otherwise. 
No need to make it more complicated than necessary.

> but as 
> you point out, there are some tricky bits of autostart/xsmp
> integration that everyone is going to have to deal with, so maybe it
> makes sense to standardize something like this?

 The tricky bits seem to me to be are rather ... ehm, philosophical than 
technical. I.e. there perhaps should be a guideline or something saying how 
autostart and XSMP should be used together, but technically I see these 
possibilities:

- Leave it as it is, people will sort it out themselves (some will probably 
use XSMP, some will do manual session management with autostart, whatever)

- Add another XSMP property stating the name of the matching 
autostart .desktop file. The session manager will somehow merge the autostart 
entry and the possibly saved session entry. This still needs manual disabling 
of the autostart entry in order to turn the thing off.

- Add a flag let's say Only-Default-Session=true to autostart .desktop files - 
session manager will launch this app only when using the default session or 
when this .desktop file is new - that will take care of becoming part of the 
XSMP session. The app, after being launched, will handle the rest using only 
XSMP. That should take care of staying part of the XSMP session. There may be 
problems if somebody actually implements more advanced session management 
support (multiple sessions).

- some more?

- 
Lubos Lunak
KDE developer
--------------------------------------------------------------
SUSE LINUX, s.r.o.   e-mail: l.lunak at suse.cz , l.lunak at kde.org
Lihovarska 1060/12   tel: +420 284 028 972
190 00 Prague 9      fax: +420 284 028 951
Czech Republic       http//www.suse.cz