OSX/MacPorts KDE CI System: Asking for trouble due to installations outside the expected $DATA_INSTALL_DIR/kf5 directory for khtml and katepart5
mk-lists at email.de
Sat Jul 5 18:47:13 UTC 2014
On 05 Jul 2014, at 20:04 , David Faure <faure at kde.org> wrote:
>> /Library/Application Support/KF5/
>> by which KF5 wouldn't clutter "/Library/Application Support" with
>> a ton of KF5-related files.
> This doesn't fit with QStandardPaths::GenericDataLocation which points to
> /Library/Application Support.
hmm, I see. Well, we’ve discussed this already a few times in the past weeks. :)
And - slowly - I am beginning to see the trickiness of all this…
Only now that the CI system is eventually building successfully even beyond KF5
I can revisit the still needed patching of the QStandardPaths for the OSX/CI
> 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>
> 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...
I’ll check and come back to this later.
> Proposals about moving stuff around have to look at the code changes that it
> implies, and whether they are actually doable (i.e. "how can some generic
> shared code find out about these files”).
I know what you mean and I don’t want to create any fuss about all this.
That said I just tried to report what I observed here on my systems and what
common sense told me. I have no clue about the inner workings of KF5 or Qt5,
as you see from what I write, so take all my comments with a grain of salt. :)
More information about the Kde-frameworks-devel