autostart spec changes

Rodrigo Moya 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:
> 
> 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 <rodrigo at gnome-db.org>




More information about the xdg mailing list