Desktop Entry Standard: Path key

[Brian J. Tarricone]

On Mon, 30 Jun 2008 09:44:43 +0200 Vincent Untz wrote:

> Le jeudi 26 juin 2008, à 10:53 -0700, Brian J. Tarricone a écrit :
> > David Faure wrote:
> > > http://bugs.kde.org/show_bug.cgi?id=164068 brings me to posting
> > > this mail here.
> > > 
> > > As far as I can see there is no support for expanding environment
> > > variables in the desktop entry standard? This is a problem for
> > > the "roaming user" feature: a user should be able to use software
> > > that creates config files and desktop files, and then move his
> > > home somewhere else and the software should keep working. Is
> > > there a solution for this problem (especially for desktop files)
> > > in other environments at the moment?
> > > 
> > > In KDE we support Key[$e]=$HOME/Documents  where the $e modifier
> > > means "expand env vars". This works fine in kconfig files, but
> > > for the Path key of desktop files, this is a violation of the
> > > desktop entry standard; more precisely it doesn't work in other
> > > environments.
> > > 
> > > Assuming a more complete specification of this [$e] thing (I'd
> > > have to ask our KConfig guys), is this a solution that would seem
> > > acceptable for the Desktop Entry Standard?
> > > 
> > > In KDE 3 we would simply use env vars and expand env vars in the
> > > Path key, without requiring [$e], but that was even more broken
> > > and non-interoperable, and we decided to be more strict about
> > > this stuff in KDE 4, so nowadays [$e] is required for this
> > > behavior.
> > 
> > I'd definitely be interested in adding something like this to
> > Xfce's menu implementation, among other things.  It seems people
> > (well, non-KDE people) around here have been pretty resistant to
> > the Key[x] modifier type thing for some reason, though.
> 
> Don't know if it was ever proposed for inclusion,

True, I'm not sure if it's ever been proposed either, but it's
definitely been brought up on more than one occasion as something KDE
has used for a while.

> but I can see why
> there's some resistance: it looks like a hack because it's done in a
> way that extends the format while staying compatible with it.

Haha, I'd call that "good design," not a hack: isn't the best way to
extend a format to find a way to do so while remaining compatible with
it?

> 
> > Personally I'd be happy with just saying that we should expand all
> > env vars always in keys where it makes sense, but obviously there
> > are backwards-compat issues with this (even though most people
> > probably won't have '$' symbols in their filenames).
> 
> I'm not opposed to expanding env vars, although it needs some
> thoughts. Is it always secure to do so, for example? What should be
> done when the environment variable is not set? etc.

You could keep a system-wide (maybe user-overrideable?) list of allowed
env vars to expand, with a set of defaults if the var isn't defined.
But then the problem there is -- what if a sysadmin decides a
'questionable' env var isn't safe to expand, and removes it?  Will a
bunch of .desktop files that assume that env var is available start
breaking?  XDG could just define a set of env vars to expand, and
ignore all others, but that strikes me as pretty inflexible.  Though
what vars might someone need?  $HOME and $USER are pretty likely.  Any
of the $XDG_-prefixed dirs, and maybe no others?  Not sure this is a
good route to take, but just throwing out ideas for further thought.

> Backwards compatibility is also an issue, indeed. That's one of the
> good things with [$e], I guess. Another approach would be to define a
> new group [XDG env vars] where keys can overload keys from [Desktop
> Entry] and use env vars -- although if we start adding groups for
> specific features, it might become a big mess at some point...

Yeah, it could be a bit ugly with extra groups -- basically all you'd
be doing is defining a new, incompatible version of the spec, and
keeping the old version around for compat reasons (with the overriding
nature just being a nice implementation optimisation).

I dunno.  I guess I'm not as well-acquainted with the use case as I'd
like to be.

	-brian