Bug 164068

Just realised it was KDE which changed my .desktop shortcuts from using full path in 'Path' to substituting /home/user with $HOME in the Properties dialog. In fact ONLY KDE3 seems to understand such notation, e.g. Gnome will fail to recognize "Path=$HOME/something" and only works with absolute paths.

So I guess KDE complies with the standards for not understanding such notation. The patch I am attaching fixes the Properties dialog to always use full path when modifying a shortcut.

However shortcuts previously modified with KDE3/KDE4 will still have Path broken.

Created attachment 25543 [details]
patch to kdelibs, fixes properties dialog

this patch will break roaming profiles, and as suck is incorrect. the real fix is to expand $HOME properly (by reading it as a path entry from the config) where ever the launching is happening. this is a pretty snaky path inside of kdelibs; and just to confirm: if you use a working path without $HOME in it, does it work properly?

The relevant code is in kdelibs/kdecore/config/kdesktopfile.cpp line 195:

QString KDesktopFile::readPath() const
{
  Q_D(const KDesktopFile);
  // NOT readPathEntry, it is not XDG-compliant. Path entries written by
  // KDE4 will be still treated as such, though.
  return d->desktopGroup.readEntry("Path", QString());
}

Well it does not look like they are treated as such. I guess replacing that with readPathEntry will fix it.

and yes, it does work by entering the full path with a text editor.

Has anything been done about this issue?
Basically, we can either change that function to use readPathEntry, disobeying the standards and breaking the path for compliant DEs (same as KDE3), however allowing roaming profiles,
or leave the runner part compliant, fix the Properties dialog to be consistent with the runner, and by that allow the shortcuts to work with other DEs, however breaking roaming profiles.

Another option would be to still be compliant, but use a KDE-private field that would allow the shortcut to work with roaming profiles in KDE. Something like Path=/home/user163/some/folder and X-KDE-UseMyHomeInPath=yes, that would tell the runner to substitute /home/* with the current user's home folder.

Created attachment 25619 [details]
kdelibs patch, adds use of X-KDE-Path

I have created a patch that fixes the issue by introducing a new variable,
X-KDE-Path that uses the notation supporting roaming profiles.

I have changed KDesktopFile::readPath to be smarter:
it first checks if Path is non-standard and reads it appropriately. Then it
checks for X-KDE-Path, reads it using KConfigGroup::readPathEntry and compares
the fully expanded paths. If X-KDE-Path started with $HOME/ (or is $HOME) and
the only difference is the name of the home folders (roaming profile, user name
changed), it returns the expanded X-KDE-Path, otherwise Path.

The properties dialog now uses the the same readPath routine as the runner
does, and when writing the changes, it writes X-KDE-Path in the portable
notation, and Path in the same format as it was before (thereby not breaking
roaming profiles for KDE3).

The right solution is to get the Desktop Entry Standard to support env vars.
Mail posted to the xdg list on freedesktop.org today.

SVN commit 824757 by dfaure:

For now, let's be consistent with kservice.cpp, so that things work even if breaks roaming.
CCBUG: 164068


 M  +2 -2      kpropertiesdialog.cpp  


WebSVN link: http://websvn.kde.org/?view=rev&revision=824757

@David: does that patch fix this bug?

I guess so, since this bug report wasn't about roaming being broken, so it basically works now for the use case described here (right Ambroz? please reopen if not).

Didn't get much out of xdg list btw, just some vague interest and concerns; ping'ed again today.