QStandardPaths::GenericDataLocation on MacOS

[Thomas Friedrichsmeier]

On Thu, 03 May 2018 21:09:03 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
> >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.

Again, this is about QStandardPaths::GenericDataLocation, exclusively.
_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
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.

Which is one reason why I don't think "just install to the offical path,
then" is an acceptable solution.

Current kate "standalone" is not a good example, because it is
_circumventing_ any QStandardPaths::GenericDataLocation lookup problems
by shipping all its data compiled in. If it did not, it would fail to
find its data files with an unpatched qt, despite following documented
code patterns.
 
> 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 

I don't care what it's called, I just need some terms to refer to this.
My monolithic, here, was referring to _all_ in one place, instead of
one app and its dependencies in one place. And yes, standalone bundles
are not really all that different from "monolithic" installs,
technically, except, it would be a typical situation to have more than
one of them at the same time.

> (and in practice
> MacPorts installs its .app bundles under /Applications, not under
> $prefix ;))

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?

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

I don't care where files are written at runtime (as long as they can be
found again). I would like not to care about where files are written at
installation time, but the sad fact is they will not be found unless
installed to one specific absolute path.

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

Nope. That will simply lead us into the situation discussed near the top
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.

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.

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

True. Any code that relies on this will likely fail on Mac _and_
Windows, so that's a valid concern. Yet, arguably, its typically going
to be a milder failure, and clearly, the prevalence is much lower
(check GneericDataLocation vs. ApplicationsLocation on lxr.kde.org). So
let's keep it in mind, but not make it a key concern while looking for
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.)

Regards
Thomas
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://mail.kde.org/pipermail/kde-mac/attachments/20180503/17a64664/attachment.sig>