QStandardPaths::GenericDataLocation on MacOS

[Thomas Friedrichsmeier]

I'll shuffle the bits in this mail a bit, in an attempt to get the
discussion back to the main topic (or at least the thing that I
intended to be the main topic):

On Thu, 03 May 2018 23:11:56 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Thursday May 03 2018 21:57:03 Thomas Friedrichsmeier wrote:
> > 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

Exactly. And that returns us to Square 1: Using GenericDataLocation
simply does not work for us on Mac, but KF5 apps use it all over the
place (encouraged by documentation). We will either have to stop using
it, today, or patch Qt (upstream / downstream).

So where do we go from here?






^This space intentionally left blank to emphasize the above.^

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

Ok, so you're talking about _installing_ to the writeable location.
Would probably work, but
1. It breaks the current separation between "vendor provided" and "user
added / customized", including the implicit protection of user files
that this provides.
2. It still does not allow for an installation to be limited to a
single arbitrary prefix, with the benefits that provides (multiple
versions / methods of installation for one application, trivial
uninstallation, easy archiving, running from thumb drives, etc.)

> > I don't care what it's called  
> 
> Still, best to avoid terms that are confusing because others
> interpret them differently.

Well, sorry for causing confusion, then. So we agree on calling the one
thing "standalone apps (bundles)", but what is the complementary term?

[...]

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

Besides any code querying ApplicationsLocation is _probably_ broken at
least on Windows, irrespective of the filesystem location. Which does
not turn this into a non-issue, but into a separate issue, that IMO
should be discussed separately (and probably requires individual
fixes, instead of and "global" measure).

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-frameworks-devel/attachments/20180504/06c1c161/attachment.sig>