QStandardPaths::GenericDataLocation on MacOS

[René J.V. Bertin]

>On Fri, May 4, 2018 at 2:38 AM, Thomas Friedrichsmeier

>> homebrew, craft). It is also about the fact that this installation
>> option causes problems, e.g. if users are to mix MacPorts and a
>> single-app-bundled KF5 app

No, that shouldn't happen, and it doesn't with the official Kate bundle. Standalone & self-sufficient also implies that you don't clash with another similar application, or even with another copy of yourself.
Bundling DBus within such a standalone app bundle and running it from there would of course be asking for trouble, but it would also make no sense at all.

>> Unix does support installing software to any prefix
>> (because it provides a way to customize lookup).

More importantly, the Unix QSP are relative to Qt's install prefix (if memory serves me well; and my patched version is too).

>> concern that this could cause problems for monolithic (macports-style)

I think you're misusing the term monolithic here? Standalone appbundles are monolithic, an aggregate framework bundle containing all KF5 frameworks would be monolithic too. Installing under a prefix that isn't the root is not what I'd call monolithic (and in practice MacPorts installs its .app bundles under /Applications, not under $prefix ;))

>improving speed as it eliminates the large number of small files) then
>we can also ensure the icons are kept compressed on disk.

Doesn't Kate already get its icons from the qresource?

>> Why would that be a problem? If something is written to the writable

It's not a problem if you don't care where those files are written. But if that's true, the whole issue can probably be avoided by determining the install locations for (shared) resources from QSP instead of hardcoding them in CMake files...

1 problem here: ApplicationsLocation. On Mac that points to /Applications (probably still without a test version - danger!), which is not at all comparable to what ApplicationsLocation is used for elsewhere.

Cheers,
R.