On Tue, 2006-02-28 at 10:42 -0700, Aaron J. Seigo wrote: > On Tuesday 28 February 2006 09:18, Rodrigo Moya wrote: > > I would propose either to choose DATA_DIRS/xdg/autostart, or use > > DATA_DIRS/autostart and make sure both GNOME/KDE include the OnlyShowIn > > field where appropriate. > > this makes the most sense IMHO. i'd be happy to add this to the kde .desktop > files that lack it. right now we install: > > irkick.desktop > kab2kabc.desktop > kalarmd.autostart.desktop > kalarm.tray.desktop > kallers.desktop > kdesktop.desktop > kgpg.desktop > klipper.desktop > konqy_preload.desktop > korgac.desktop > ktip.desktop > panel.desktop > restore_kmix_volumes.desktop > > of those the following are OnlyShowIn=KDE or are not actually autostarted by > default: > what do you mean with this, that they have the Hidden key set to False by default?
> kab2kabc.desktop > kdesktop.desktop > khotkeys.desktop > konqy_preload.desktop > korgac.desktop > panel.desktop > > leaving us with: > > irkick.desktop > kalarmd.autostart.desktop > kalarm.tray.desktop > kdesktop.desktop > kgpg.desktop > klipper.desktop > konqy_preload.desktop > restore_kmix_volumes.desktop > > these are murkier entries since one may want to use, for instance, kgpg or > kontact (and therefore kalarm) in a non-KDE desktop env. > yes, or one might want to enable them only for one desktop. So I guess we need to allow the user to set the OnlyShowIn field from the specific desktop's configuration GUI. What to use by default is another question. I guess they should use OnlyShowIn=GNOME|KDE by default, and then let the user change as he/she wills. > all of those "murkier" cases have an X-KDE-autostart-condition entry in > their .desktop files, the value of which is a 4 value comma separated list: > > configfile,configgroup,configkey,default > > e.g.: > > X-KDE-autostart-condition=kgpgrc:User Interface:AutoStart:false > > it may be worthwhile to implement autostart-condition in the spec so that we > can keep these autostart entries but not bung up the user experience > otherwise. > yes, sounds good > the complications i see here are: > > 0. being able to access kconfig settings from a gconf using app and vice versa > right, because for gnome entries we need to use a key path, not a config file. And of course both gnome and kde need to be able to access the other desktop's configuration :( > 1. being able to alter the default based on whether it's in its "native" env > of not. e.g. in KDE perhaps kgpg should default to true, but outside of KDE > perhaps it should require user intervention to have it autostart. > yes > for complication #0, in kde4 we will likely have the ability to use elektra > as > a kconfig backend allowing us to access gconf settings if available. any > chance that gconf will get something similar? > the kde config is in plain files? I guess we could have a backend that maps the KDE config to gconf. > > Also, when disabling services by using the Hidden field, there should be > > a way for admins to disable this. That is, a CantBeDisabled field (or > > whatever) that disables any .desktop file with the same name in other > > top-level directories. > > we (KDE) have this via immutability ([$i]) already. it's a sensible and > generic (e.g. doesn't just apply to autostard) method IMHO. i'd recommend > using that approach as it's already widely implemented in KDE and has years > of use that shows it works well for all parties involved (coders, sys admins, > etc) > I'd prefer a separate field, but if you are already using this in KDE, sounds good to me. -- Rodrigo Moya <[EMAIL PROTECTED]> _______________________________________________ xdg mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/xdg
