autostart spec changes

[Waldo Bastian]

So what is the plan here? Do we want to use XDG_DATA_DIRS/autostart instead of 
XDG_CONFIG_DIRS/autostart going forward and clean up the current 
interoperability problems caused by existing KDE entries that weren't 
expected to be picked up by Gnome?

If so, what parts of X-KDE-autostart-condition, X-KDE-autostart-phase and 
immutability [$i] should be added to the autostart spec? I suggest to leave 
the X-KDE-stuff  "implementation specific" and just add some clarification to 
the spec that recommends the use of OnlyShowIn=KDE if you need to rely on any 
of these features.

Personally I think XDG_CONFIG_DIRS/autostart remains a better choice and makes 
a smoother transition but I'm happy to settle on anything that offers common 
autostart functionality and that people can agree on.

Cheers,
Waldo

On Wednesday 01 March 2006 04:08, Rodrigo Moya wrote:
> 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.

-- 
Linux Client Architect - Channel Platform Solutions Group - Intel Corporation
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20060321/29415cf0/attachment.sig>
-------------- next part --------------
_______________________________________________
xdg mailing list
xdg at lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xdg