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]

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 
framework)...
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 
DATADIR/khtml/khtml5.rc

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>