QStandardPaths::GenericDataLocation on MacOS

[Ben Cooksley]

On Fri, May 4, 2018 at 2:38 AM, Thomas Friedrichsmeier
<thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
> 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.

It is worth noting that at one point we had a much lighter (only about
20MB or so I think) DMG however that broke icon support.
There is definitely space for optimisation here in terms of what we're
including in the .app bundle.

If we end up going down the QRC route (which also has the advantage of
improving speed as it eliminates the large number of small files) then
we can also ensure the icons are kept compressed on disk.

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

Cheers,
Ben