OSX/MacPorts KDE CI System: Asking for trouble due to installations outside the expected $DATA_INSTALL_DIR/kf5 directory for khtml and katepart5

David Faure faure at kde.org
Sun Jul 6 09:41:26 UTC 2014

On Saturday 05 July 2014 20:47:13 Marko Käning wrote:
> > This is the issue: there isn't just "one vendor". Anyone can build apps on
> > top of Qt and KF5. So we can't hardcode a vendor in Qt or KF5 APIs.
> Well, I thought, that the frameworks themselves have a vendor, namely KDE!
> System-wide framework-specific configuration could then go into
> 	/Library/Application Support/KDE/<framework name>
> couldn’t it?

Framework-specific yes. But again, take the case of kxmlgui files as an 
example. They are loaded by the kxmlgui framework itself, whether they got 
installed by a kde framework, a kde app, a non-kde app (= an application not 
developed by the KDE community ("vendor") but still using the KXmlGui 
If each of these installs .rc files in a randomly named location, how is 
KXmlGui supported to find them?
The current solution is
 <DATADIR>/<application name>/foo.rc

Where I say <application name>, it's rather <component name>, where "khtml" is 
a component too, for instance. This is why we end up with 

The only other solution I can think of is
 <DATADIR>/kxmlgui5/<application name>/foo.rc
i.e. grouping by technology rather than by vendor or application.
In fact, we already do this with share/knotifications5/*.notifyrc and 
share/kservices5/*.desktop -- for the same reasons. So let's go for that.

This can be done with the attached patches.
Everyone: please review :)
I'll upload the kxmlgui one to reviewboard since it's larger.

SC/BC is kept, the files can be loaded from the "old" locations, with a 
runtime warning.

Marko, if this goes in, can you port everything kf5-based to install .rc files 
in KXMLGUI_INSTALL_DIR just like kwrite.diff does for kwrite?

> > We could design APIs that force passing a vendor string,
> > or we could use the name of the technology as the vendor string,
> > like /Library/Application Support/KXMLGUI but that would mean that every
> > app would end up installing something in there, rather than in
> > /Library/Application Support/<application name>.
> Well, I thought the vendor string was there. At least I remember to have
> seen code like that in QStandardPaths...

Not in GenericDataLocation, which is DATADIR.
There's this weird old DataLocation which appends org domain and app name to 
the DATADIR, I find that totally useless, it assume monolithic apps rather 
than components which can live in the same process (i.e. same domain name and 
same app name).

David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: ecm.diff
Type: text/x-patch
Size: 2030 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140706/b388fc1e/attachment-0003.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kwrite.diff
Type: text/x-patch
Size: 545 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140706/b388fc1e/attachment-0004.diff>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kxmlgui.diff
Type: text/x-patch
Size: 1757 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-frameworks-devel/attachments/20140706/b388fc1e/attachment-0005.diff>

More information about the Kde-frameworks-devel mailing list