kde4support: kstandarddirs_unittest fix

[David Faure]

On Monday 23 December 2013 14:51:19 Alex Merry wrote:
> If $PREFIX/share/applications does not exist, KStandardDirs will not add
> it.  It will then notice that nothing matching the installation prefix
> was added, and add installPath("xdgdata-apps"), which is
> $PREFIX/share/applications/kde5/.

OK, sounds like that bit of code is broken and should have added 
share/applications instead, i.e. NOT simply installPath().

> However, if $PREFIX/share/applications *does* exist, it will add it
> (regardless of XDG_DATA_DIRS, because it *always* considers
> installPath("kdedir")/share - as well as each $KDEDIRS/share - to be in
> XDG_DATA_DIRS), and then *not* add installPath("xdgdata-apps"), because
> it determines the installation prefix to have already been dealt with.
> 
> Now, a comment in kstandarddirs.cpp (line 1870) says that the latter
> case is the correct behaviour; I'm guessing that when you wrote that
> (2008), you didn't anticipate the possibility that the installation
> directory might not contain share/applications, since KIO installs a
> couple of desktop files.

Yeah, it's supposed to just always exist.

> I guess a possible solution is to change the return value of
> installPath("xdgdata-apps") to not include the trailing kde5.

Yes, that sounds like the right fix. It will not change were we actually 
install the files, it simply returns the base dir for the installation path.

> Actually, I think we should just install application files directly in
> share/applications. (ie: change the value of XDG_APPS_INSTALL_DIR in
> KDEInstallDirs.cmake).  It makes everyone's lives more difficult to have
> subdirectories (as I discovered while creating and implementing the
> MPRIS2 spec - how do you tell applications how to find Amarok's desktop
> file: "amarok.desktop" won't work, because it's not in
> share/applications, but "kde4-amarok.desktop" or "kde/amarok.desktop"
> requires knowing something about the buildsystem magic that installs the
> desktop file).

Ah, if only Waldo was still here. I'm not sure exactly what the reasoning for 
subdirs under applications was. There's different methods in KService and 
KToolInvocation for dealing with this, i.e. if you had used 
findServiceByDesktopName rather than ByDesktopPath it should have worked iirc.
But yeah - "namespacing" of desktop files doesn't sound that useful, when the 
binaries are all in the same bin dir anyway.

I just hope I'm not overlooking something by giving you a green light for 
changing this, because I wasn't the author of the original decision.

But yeah, go ahead, I can't think of a reason why not.

Maybe this was related to the idea of having some binaries in libexec (which 
can therefore be versionned), but we're not doing this (after other DEs 
complained), and we can just append a '5' (to both the executable name and the 
desktop file name) for the same effect.

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE, in particular KDE Frameworks 5