Why is plasma-framework using /usr/share/kde5?

[Daniel Vrátil]

On Monday 21 of April 2014 17:32:10 you wrote:
> On Tuesday 15 April 2014 18:14:36 Daniel Vrátil wrote:
> > Hi,
> > 
> > I'm wondering why Plasma Framework installs it's .desktop files to
> > /usr/share/kde5 by default? It causes some confusion for packagers:
> > 
> > No other framework is using a namespace in /usr/share, they all install
> > into /usr/share/$FrameworkName.
> 
> I don't see that here.
> 
> $ find /d/kde/inst/kde_frameworks -name services
> /d/kde/inst/kde_frameworks/share/plasma/services
> /d/kde/inst/kde_frameworks/share/kde5/services
> /d/kde/inst/kde_frameworks/share/dbus-1/services
> /d/kde/inst/kde_frameworks/share/konqsidebartng/virtual_folders/services
> 
> The first one, plasma/services, only has some *.operations files.
> 
> The second one, share/kde5/services/, has all the Type=Service .desktop
> files from many places (khtml, plasma, kate, baloo, kdevelop, kcm....).
> 
> So this seems consistent to me (unlike your description).

I find the inconsistency in some Framework(s?) using a kde5 (or kf5, does not 
matter) directory "namespace", while others don't. Either all frameworks 
should install to /usr/share/kf5/$framework, or none should. Having 
/usr/share/services could however lead to various kinds of troubles, so I 
understand the need for the namespace here, but then I'd expect it everywhere 
by default.

> This needs to be a single directory, it can't be /usr/share/plasma because
> kbuildsycoca5 needs to find all service .desktop files. It's a global
> database of plugins/services, we can't spread it out.
>
> > So why does Plasma framework? And if it has to
> > use namespace (but please explain me why), then it should be
> > /usr/share/kf5, not /usr/share/kde5, same as we have /usr/include/KF5 and
> > not /usr/include/KDE5.
> 
> We can rename kde5 to kf5. It was actually suggested in the past.
> It's just a bit weird though: /usr/include/KF5 is actually provided by KF5,
> while here we're talking about plugins provided by the applications.
> The naming kde5 is historic indeed, but the naming kf5 is arguable.
> 
> Re Alex Merry's suggestion, at least kde5 or kf5 has a '5' in the name,
> providing co-installability with version 6 :-).
> That argument would lead to "kservice5", I guess. But not all files in there
> are related to kservice - e.g. *.protocol files, which are for kio, or
> ServiceMenus which are for dolphin.

This is a good point. So what about co-installability of Plasma framework 
version 5 and 6 (/usr/share/plasma), KHTML (/usr/share/khtml), KXMLGui 
(/usr/share/kxmlgui), KJS (/usr/share/kjs). KDocTools is using 
/usr/share/kdoctools5, so is it expected to have kdoctools6 at some point - 
why not kservice6? :-) 

> IMHO the naming doesn't matter that much, as long as kbuildsycoca5 can find
> the files.

Sort of.  If you want to develop an application that depends on KService only, 
why should it use /usr/share/kde5/services if it has nothing to do with KDE?

Dan

-- 
Daniel Vrátil | dvratil at redhat.com | dvratil on #kde-devel, #kontact, #akonadi
KDE Desktop Team
Associate Software Engineer, Red Hat, Inc.

GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140422/54566c86/attachment.sig>