autostart spec changes
rodrigo at gnome-db.org
Wed Mar 1 14:08:11 EET 2006
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:
> of those the following are OnlyShowIn=KDE or are not actually autostarted by
what do you mean with this, that they have the Hidden key set to False
> leaving us with:
> 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
> 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:
> 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
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.
> 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,
I'd prefer a separate field, but if you are already using this in KDE,
sounds good to me.
Rodrigo Moya <rodrigo at gnome-db.org>
More information about the xdg