QStandardPaths::GenericDataLocation on MacOS

Thu May 3 19:25:50 UTC 2018

Hi,

> 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
I still think going the QRC way is the simplest solution.
With that, at least in Kate (that uses a lot of frameworks), I am not aware
of any real remaining issue with qstandardpaths.

You can go the monolithic app bundle way with that or the "I share stuff" way
like on Linux.

Actually all frameworks I patched use the QRC way on Linux nowadays, too,
which IMHO has no real drawbacks and even avoids a lot of hassle during
deployment for e.g. Windows (where a lot of small files do suck incredibly
more than on Unices with a decent filesystem).

Much harder is the issue of deploying all plugins/... that are bundled with
the application in a app bundle, as e.g. stuff like my macqtdeploy patch
to patch the kio plugins and co. just rot away in the qt bug tracker.

https://bugreports.qt.io/browse/QTBUG-48836

Greetings
Christoph

-- 
----------------------------- Dr.-Ing. Christoph Cullmann ---------
AbsInt Angewandte Informatik GmbH      Email: cullmann at AbsInt.com
Science Park 1                         Tel:   +49-681-38360-22
66123 Saarbrücken                      Fax:   +49-681-38360-20
GERMANY                                WWW:   http://www.AbsInt.com
--------------------------------------------------------------------
Geschäftsführung: Dr.-Ing. Christian Ferdinand
Eingetragen im Handelsregister des Amtsgerichts Saarbrücken, HRB 11234