[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-mac
Subject:    Re: QStandardPaths::GenericDataLocation on MacOS
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2018-05-03 21:11:56
Message-ID: 3895815.xj1Kza6nLc () portia ! local
[Download RAW message or body]

On Thursday May 03 2018 21:57:03 Thomas Friedrichsmeier wrote:

> _If_ applications were to actually install to the current paths defined
> for that on Mac "Library/Application Support", and "~Library/Application
> Support", on more, no less, _then_ clashes would start to happen. As

A priori no, because the Application Support directory shouldn't be written to \
directly (as per Apple's rules) but should contain subdirectories, e.g. \
/Library/Application Support/Kate . I've never really looked at how that works in \
practice, but I strongly doubt that code has to append this subdirectory itself, \
that'd be contrary to the QSP purpose.

> far as I am aware, _none_ of the current installation approaches for
> KF5 does so, and as a consequence they all fail GenericDataLocation
> lookup with an unpatched qt.

Nope; my hope is that this would remove the need for patching QSP. As you said \
yourself, files written to a QSP location at runtime can be found again through QSP. \
That should apply to files written during the install step too (as if the application \
writes them to that location during its first run).

> I don't care what it's called

Still, best to avoid terms that are confusing because others interpret them \
differently.

> Ah, good reminder. But it doesn't install anything under /Library, does
> it? Which is why MacPorts, too, cannot support KF5 with a non-patched
> QStandardPaths, right?

Good question, actually, because this doesn't apply only to KF5 code. It's not \
forbidden to install things outside $prefix, but it's discouraged. I'm not aware of \
any "pure Qt5" application which installs things into /Library/Application Support

> of this mail. Besides, _if_ we are both talking about the option of
> using an _unpatched_ Qt, then hardcoding or querying QSP makes very
> little practical difference.

One very important difference: querying should work on all platforms, so remove the \
need for conditional code.

> I understand you'd like to see ECM to continue to support your
> "Unix-like" patched QSP, and why not? ECM is under "our" control
> anyway, but the issue at hand is one that cannot be solved in ECM alone.

Forgive me if I'm not entirely reassured that there won't be CMake code at some point \
that simply checks `if(APPLE)` to decide whether or not to use tweaks for generating \
standalone app bundles (Marble does, and its devs have simply ignored my proposed \
patch to reenable "linuxy" builds).

> Windows, so that's a valid concern. Yet, arguably, its typically going
> to be a milder failure, and clearly, the prevalence is much lower

Until you run the unittests and one of those just trashes ApplicationsLocation when \
it's done. That actually happened to me, and I still can't believe I actually caught \
that before my entire /Applications had disappeared.

> a path forward. (And in fact, I'm a bit at a loss to see how to solve
> _that_, short of, again, installing everything to a single absolute
> location.)

The usual content of ApplicationsLocation (.desktop files) probably makes no sense \
anyway for standalone app bundles that are not expected to play nice with \
applications following FreeDesktop protocols. IOW, those files could be skipped \
during the installation step in standalone build mode (again, not simply \
`if(APPLE)`).

Anyway, I don't want to monopolise this thread and I'm beginning to feel that's \
exactly what I'm doing. Apologies.

R.


[prev in list] [next in list] [prev in thread] [next in thread]