[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-frameworks-devel
Subject:    Re: QStandardPaths::GenericDataLocation on MacOS
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2018-05-03 14:01:46
Message-ID: 2225429.SYDlUh7QcT () bola
[Download RAW message or body]

On Thursday May 03 2018 15:19:33 Thomas Friedrichsmeier wrote:

Hi,

> 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.
Also, what are the chances that this will be overhauled anyway for Qt6?

> install to /Library/Application Support. But that solution has obvious
> limitations that I would like to avoid, and - by analogy to Unix
> _and_ Windows - are entirely avoidable.

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.

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

> 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 \
it gets through DBus, uses the alien-looking Breeze icons and default colour palette, \
plus the "native" Mac widget style which makes it look like an application for the \
visually impaired (everything way too big). It works, but IMHO no longer has any \
advantages over well-established truly native competitors like BBEdit (which clocks \
                in at 32Mb *uncompressed*).
And: supposing those 88Mb are the uncompressed app bundle size, how much of that has \
to be duplicated in each and every app that uses the Kate kpart?

> I'm absolutely aware of that. The question is simply: Would MacPorts
> tolaterate a symlink from /opt/local/Resources to /opt/local/share

They probably wouldn't like it, but if the dislike is strong enough it will lead to a \
small patch that undoes or modifies the change. Careful though, <APPDIR> should \
probably be something like QLibraryInfo::prefixPath and not the method from \
QApplication which will point to the MacOS directory inside the app bundle.

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

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.

Which reminds me that I've already suggested several times that it would be useful to \
rethink the build system so that it determines the install locations based on QSP \
(using qtpaths or a dedicated small utility).

Cheers,
R.


[prev in list] [next in list] [prev in thread] [next in thread]