QStandardPaths::GenericDataLocation on MacOS

[Thomas Friedrichsmeier]

Hi,

I'll just answer a few select points, because, yes I am aware this has
a tiny bit of a history, and I don't want to see a repeat. The master
plan is actually to get David Faure to champion a solution (whichever
one) into Qt. So before getting lost in the detail of the various
approaches, I'd like to hear a word on the general direction that seems
most promising.

On Thu, 03 May 2018 11:24:51 +0200
René J.V. Bertin <rjvbertin at gmail.com> wrote:
[...]
> What is often overlooked is that not all of Apple's own (and
> 3rd-party) software installs via simple DMGs, notably applications
> that depend on or provide shared resources. I would assume that
> iTunes still installs via an installer, for instance.

True, yet another route would be to simply require KF5-based apps to
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.

> There are individual project efforts that manage to get a working
> standalone app bundle using an unpatched Qt and QSP. [...]

It's not even hard for individual apps, today. Just compile in all
data files as qresources, and the problem is done with. As an
application maintainer that is my fallback plan. But it's not really my
preferred vision for KF5 as a whole.

> But in the end it's the KDE model itself that cannot easily (if at
> all) be adapted to desktop systems like Macs and MSWin PCs if you do
> not want to provide a central install of the shared resources
> including certain external dependencies like DBus.

Yes, but "central" is pretty relative, here. I know single app
installers are not your vision of KF5 on Mac, and I certainly don't
want to push them as _the_ way to go, but to be honest, I'm quite
impressed with the .dmg's created on the binary-factory for Mac, today.
A fully packaged Kate is available at 88MB download for instance,
despite including a whole bunch of frameworks.

Yet that seems mostly orthogonal to the issue at hand to me. Both
monolithic and single app installation are facing the same problem
right now, and essentially need (one of) the same solution to be able
to fix it.

> >Not sure about the MacPorts-take on doing something like this, but
> >for  
> 
> MacPorts (and Fink, which still exists!) use a single prefix in which
> everything is installed like Gentoo Prefix or pkgsrc would do it.

I'm absolutely aware of that. The question is simply: Would MacPorts
tolaterate a symlink from /opt/local/Resources to /opt/local/share
(/opt/local being the installation prefix)? If so, the simple patch I
presented should immediately allow a clean way forward for KF5 on
MacPorts (if upstreamed).

> Patch size is not a problem at least if the patch is potentially
> upstreamable.

But it could be, if the responsible reviewer is a bit uninterested...

> The problem I see with qt.conf is that it is
> application-specific; each app bundle will have to provide its own
> copy.

True, but so what, if it can be generated, automatically.

> The alternative would be to convince Christoph Cullmann and
> like-minded people to work on a way to mould their respective
> approaches for building standalone app bundles into something that
> can be added to the ECM.

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.

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-mac/attachments/20180503/e2ba5c2e/attachment.sig>