QStandardPaths::GenericDataLocation on MacOS

[Thomas Friedrichsmeier]

Hi,

On Thu, 03 May 2018 16:01:46 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
> On Thursday May 03 2018 15:19:33 Thomas Friedrichsmeier wrote:
> >plan is actually to get David Faure to champion a solution (whichever
> >one) into Qt.   
> 
> I can be wrong, but I don't see that happening beyond his general
> support.

well, let's hear him on this.

> I don't see what Unix does here. /Library/Application Support is just
> the OS X equivalent of $prefix/share and maybe parts of
> $prefix/libexec; both are central, shared location that have a
> per-user equivalent (~/Library/Application Support and
> ~/.local/share). The limitations I see are purely and only related to
> the way software has to be installed.

Yes, it's about the installation options. It is _primarily_ about the
fact that the one theorically possible installation option on Mac
matches with _none_ of the major available solutions (macports,
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, or two versions of a KF5 app, or many other
not-so-unlikely scenarios.

Unix does support installing software to any prefix
(because it provides a way to customize lookup). Windows supports
installing software to any prefix (because it includes an
installation-relative path in the list of paths for
GenericDataLocation). Mac does not, because it lacks both (even though
installation-relative paths are available in other QStandardPaths).

> >It's not even hard for individual apps, today. Just compile in all
> >data files as qresources, and the problem is done with.  
> 
> That may be true for resources that contain no executable native
> code, but it probably won't work for libraries and plugins.

Those can be handled in qt.conf (and macdeployqt auto-generates an
appropriate qt.conf, for instance). That may or may not be our favorite
solution, but it is an already available option (and if there is a
concern that this could cause problems for monolithic (macports-style)
installations, qt.conf can even be provided as a per-app qresource,
which in principle, should be possible to generate, and compile into
each binary, automatically.
 
> >A fully packaged Kate is available at 88MB download for instance,
> >despite including a whole bunch of frameworks.  
> 
> But with that you get a version of the application that just drops
> the functionality [...]

I just don't want to get into that discussion, at all, here. I
absolutely see use-cases for both "monolithic" and "single app"
installations. So both should be supported. Currently neither is. So
the issue at hand isn't to discuss which of the two is superior, but to
find out how to fix the problem affecting them both.

> >Again, I think this is not an either-or situation. Both centralized
> >and standalone app installations are affected by this problem, unless
> >relying on .qrc files, exclusively.  
> 
> There *is* an either-or situation: work with the existing
> QStandardPaths or don't. Kate.app shows that the former is not
> impossible, and it has the big advantage that you do everything
> in-house without modifying Qt.

QRC, sing it with me. That's the whole secret, as far as I am aware:
Circumventing the problem by not installing files. Since I found out
about this, I sleep a lot better as maintainer of RKWard, but it still
bugs me, severly, for KF5 as a whole.

> Another thing: it seems that in your reasoning you have only
> considered the search algorithms for finding readable locations. For
> the writable locations you cannot simply append a "compatibility"
> location, and in turn that means that resources generated at runtime
> will later be found in "native" Mac locations because QSP will return
> the first location that has the requested file.

Why would that be a problem? If something is written to the writable
location, it will then later be found. Sure, that's the point, isn't it.
Possibly by a different application, or by a different version of the
same application. Also true, but nothing new.

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/20180503/1edd2f5a/attachment.sig>