autostart spec updates/extensions

[Dan Winship]

Vincent Untz wrote:
> Hi,
> 
> Am I really the first to reply? :-)

Yeah. I posted it right before aKademy started, so the KDE developers
had an excuse for not replying for a while... If no one else replies, I
was planning on pulling the old "well, here are my diffs to the spec, if
no one objects, I'll commit them" trick to get people to comment. :)

>> So I'd argue with sticking with $XDG_CONFIG_DIRS/autostart. Is anyone
>> really horribly opposed to this?
> 
> If I were a Debian developer (but I'm not :-)), I'd argue that we should
> use $XDG_DATA_DIRS/autostart for the .desktop files shipped in packages
> and $XDG_CONFIG_DIRS/autostart for .desktop files modified by
> administrators.
> 
> This would make sense, but this might be a bit far-stretched.

I'm voting for far-stretched...

>> 2. Immutability / Lockdown
> 
> [...]
> 
> I like the [$i] group idea.
> FWIW, updating the desktop entry spec would be hard right now since we
> don't talk about "inheritance" there.

Good point.

>> 3. X-KDE-autostart-condition
...
>> 	exists: The key name is a filename relative to
>> 	  $XDG_CONFIG_HOME; if the file exists, the key is "true".
> 
> (except where the filename starts with / and then it's an absolute
> filename)

An easy change, but would it actually be used? If you want to globally
disable the application, you can just remove the .desktop file.
Autostart-Condition is only useful when some users will want the app
enabled and some won't.

>>       Autostart-Condition: x-environment-variable:$FOO_ENABLED
> 
> environment-variable should probably standardized since it's easily
> implementable and useful.

We could specify an arbitrary number of non-gconf non-kconfig
mechanisms, but we really only need one.

"x-environment-variable" was supposed to be just an example of something
that "someone else" might do that you don't know about. Maybe I'll
change it to:

         Autostart-Condition: x-moon-phase:waxing gibbous

:-)

> ++ for this addition.

OK, cool. I wasn't sure if other people would think the idea was total
crack. :)

> It might be useful to specify more than one Autostart-Condition, though
> (for example, a kconfig one and a gconf one). How could we deal with
> this? Or is it really a case we can safely ignore?

Again, I'd want to see an actual use case...

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

So that would yield a 5-phase system: SETUP, WINDOWMANAGER, PANELS,
DESKTOP, and APPLICATIONS. Or something.

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

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.

Thanks for you comments.

-- Dan