>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 _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
