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

[Marko Käning]

Hi David,

On 06 Jul 2014, at 11:41 , David Faure <faure at kde.org> wrote:
> 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)…
yes.

> If each of these installs .rc files in a randomly named location, how is 
> KXmlGui supported to find them?
I see your point.

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

> 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.
That sounds like a plan to me.

> This can be done with the attached patches.
> Everyone: please review :)
> I'll upload the kxmlgui one to reviewboard since it's larger.
I’ve made it a favourite on my dashboard right away.
 
> SC/BC is kept,
What’s SC/BC. I can think of “backwards compatibility” for BC, though.

> the files can be loaded from the "old" locations, with a  runtime warning.
That’s nice.

> 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 write?
I don’t think that I’ll be able to do that soonish, as it seems to be a rather
large undertaking, given that we’ve got quite a few frameworks. :)

Well, first I need to be able to also RUN e.g. kate (just like kwrite) to be
able to actually perform a job like that. But, since both are crashing during
startup on the OSX/CI system, I am about to write a few b.k.o. tickets first!

Afterwards I’ll pursue that, sure.

>> 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).
That’s what I had seen, yes. :)
OK, if it is of no use...

Greets,
Marko