autostart spec updates/extensions

[Lubos Lunak]

On Sunday 08 October 2006 23:26, Dan Winship wrote:
> Vincent Untz wrote:
> >> 4. Other KDE extensions?
> >>
> >> Are there any other extensions from KDE autostart that we should
> >> absorb? The only other one I'm aware of is X-KDE-autostart-phase.
> >>
> >> Having some sort of priority/phase system seems like a good idea.
> >
> > Agree. Priority is the simplest way to do this. I don't know if we'd
> > want to have a depend/provide key since this could make things a bit too
> > complex.
>
> Priority also has the advantage of being compatible with the current
> GNOME system. KDE uses phases though, and I'm wondering if that may be
> better; you don't really need control of the *exact* order of every
> application. You just want to make sure that (1) certain things start
> really really early (eg, gnome-settings-daemon), (2) the window manager
> (and compositing manager, etc) start before any windows are mapped, (3)
> windows with struts (ie, the panel) get mapped before anything else [so
> we don't need to move things around after the panel carves out its part
> of the screen], (4) the desktop manager / file manager starts before
> ordinary apps [not totally sure this is true, but both GNOME and KDE
> seem to do it].

 Yes, more or less. We have X-KDE-autostart-after, but all the usage cases 
were only after kdesktop or after kicker, so I just deprecated it and 
introduced phases during the recent startup reordering.

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

> >> 7. XSMP
> >>
> >> Given that XSMP and autostart are closely tied together, and given
> >> that XSMP is annoyingly underspecified, it seems to me like it might
> >> be nice to put some XSMP clarifications into the autostart spec
> >> (though maybe others would feel that this is just as out of place as
> >> the autorun stuff?)
> >
> > Makes more sense to clarify the spec somewhere else, IMHO. We already
> > have something similar for the X clipboard:
> > 	http://freedesktop.org/wiki/Standards_2fclipboards_2dspec
>
> 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?

> There are also some XSMP extensions I'd like to propose at some point.
> (Eg, a property to specify whatever we decide on for priority or phase,
> and a property to specify the application's .desktop file, so the
> session manager can get an icon and a localized name for the app.)
>
> > I have another question: should a .desktop file in .config/autostart/
> > be able to depend on the content of another one in
> > /etc/xdg/autostart?
>
> The spec says no, you only look at the file in the highest-priority
> directory, and ignore the other one completely. So if you create a
> personal autostart file that's a modified version of a global one, you
> should copy the entire .desktop file and make the changes you want,
> rather than only writing out the diffs.

 As already mentioned, that seems very wrong.

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