kde4support: kstandarddirs_unittest fix

[Kevin Ottens]

Hello,

Any news on that front? I see kde4support is still the one not green because 
of that test.

I see that Alex is kind of waiting for someone to take a side on the possible 
solutions. See below for my own take but I don't know KStandardDirs enough to 
have a valuable opinion.

/me looks at David.

On Monday 23 December 2013 14:51:19 Alex Merry wrote:
> On 21/12/13 11:23, Alex Merry wrote:
> > KStandardDirs does not add directories that do not exist, UNLESS they
> > are the directory returned by installPrefix().  kde4support does not
> > install anything in share/applications, therefore if you install
> > kde4support in its own prefix, $PREFIX/share/applications does not get
> > added to the resource dirs regardless of what you might set
> > XDG_DATA_DIRS to.
> 
> Ah, it turns out to be more complicated than that.  While I fixed
> Jenkins, I broke the test for people who install everything to the same
> location (ie: pretty much everyone).
> 
> 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/.
> 
> 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.
> 
> I guess a possible solution is to change the return value of
> installPath("xdgdata-apps") to not include the trailing kde5.

I guess that could be OK since it's in kde4support and at the time this path 
didn't exist anyway.

> 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).

Definitely something which would need a closer look. I feel that wouldn't help 
for co-installability though.

Regards.
-- 
Kévin Ottens, http://ervin.ipsquad.net

KDAB - proud supporter of KDE, http://www.kdab.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20131227/20019f8e/attachment.sig>