Hidden/Enabled key in autostart spec

Bastian, Waldo waldo.bastian at intel.com
Fri Oct 27 19:49:05 EEST 2006


>What I would really like to see is that the autostart stuff can be
>merged into the normal desktop files that show up in the menus. In
>this case, Hidden should be used to state that it shouldn't appear
>in the menus.

"NoDisplay" means it shouldn't appear.
"Hidden" means to pretend it doesn't exist.

>We could then have another key called Autostart in
>the desktop file spec, which specifies whether or not something is
>to be automatically started. This would make it much easier to have
>add/remove to/from autostart, integrated with the menu system, and
>would simplify how ISVs provide autostart files, as they won't have
>to provide the same .desktop file multiple times in different paths.
>
>I imagine the reason it isn't being done this way, is due to the
>potential performance concerns of loading up the menu tree on every
>log-in. We can probably easily resolve this with caching, or some
>other way. The panel and/or some other things may be loading up
>the menus already anyway, because they need to display them to the
>user.

It is a critical performance path. KDE has a cache for desktop files but
delays updating it's cache till after the session has started to reduce
the login time.

It's mostly for conceptual reasons though that I rather see the control
over whether to autostart something handled elsewhere. With the menu
system we have the .desktop files which are a static representation of
application properties, and then we have the menu layout itself which
reflects policy. The two are, for this very reason, split between
XDG_DATA_DIRS (static data) and XDG_CONFIG_DIRS (policy). Whether to
autostart something belongs under XDG_CONFIG_DIRS.

If you want to keep all .desktop files in one place, I suggest to put a
single mechanism in place under XDG_CONFIG_DIRS that indicates which
apps to autostart by referencing .desktop files under XDG_DATA_DIRS
already in the menu system. Maybe something like default.lst (Although
for some reason that one lives  in XDG_DATA_DIRS)

Cheers,
Waldo



More information about the xdg mailing list