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 | dvra...@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
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel