QStandardPaths::GenericDataLocation on MacOS

[René J.V. Bertin]

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.