QStandardPaths::GenericDataLocation on MacOS

[René J.V. Bertin]

On Thursday May 03 2018 10:02:35 Thomas Friedrichsmeier wrote:

Hi,

I have mostly skimmed over your long email but allow me to warn you firsthand that I've tried to get feedback and constructive collaboration like this before and never got very far because the prevailing attitude is 1) don't patch Qt and 2) be as Mac'ish as possible (without necessarily having a lot of experience with what that actually means).

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.

There are individual project efforts that manage to get a working standalone app bundle using an unpatched Qt and QSP. It is rather evident that this should be possible because Qt designed QSP for this purpose AND to allow using Qt for apps offered via Apple's app store. This works well enough for applications that don't don't depend on others and don't need DBus to advertise their services.

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. On Mac the "native" way to do that would be a single framework in /Library/Frameworks which bundles all KF5 frameworks like certain of Apple's frameworks contain multiple sub-frameworks, plus a corresponding store in /Library/Application Support where other KF5 libraries, plugins etc. can install their support files.
That would of course represent a huge effort that should have been started immediately with KF5 5.0.0 .

A couple of years into "supporting" KF5 on Mac and trying to get traction for it on/in MacPorts I have come to the conclusion that there just is no demand beyond possibly the few applications that are sufficiently self-sufficient to be offered "as an icon on a DMG"; Kate, probably KDevelop, Krita and possibly the other Calligra members and maybe a handful of others. digiKam has a Mac installer, apparently its target audience is expected to have enough computer literacy to know what to do with one of those :)

About MacPorts and official KF5 ports: unlikely to happen unless someone else is willing to recreate ports so you get a sensible experience with the unpatched Qt5 provided by the official Qt5 port (or adapt my KF5 ports minimally to that effect). The hurdle here is that I've never been able to arrive at a constructive collaboration with the Qt5 port maintainer; without that there will be no official alternative Qt5 port for use with KDE and we'll remain stuck with the need for a custom ports tree.

>1. It requires "smart" installers and uninstallers, will not work with
>plain .dmg's.
>2. Once installed, an application cannot trivially be moved, any more,
>as that would also require adjusting the symlinks.

>3. It only really works for a single centralized installation. However,
>if installing two KF5-based applications AppA and AppB to separate
>installation roots, where would - for instance - ~/Library/Application
>Support/kxmlgui5 point to? A directory inside AppA's installation
>root, or inside AppB's installation root? It cannot be both.
>
>appropriate. The drawbacks I can think of:
>1. A rather large patch

It is largish because designed with upstreamability in mind and I thin it also still contains echoes of earlier approaches that could be removed. A patch for a Qt version only to be used with KF5 code can be a lot leaner.
The stale ticket you refer to is probably the one on which it was said that the Qt devs are open for this kind of patch, provided it is well justified (argued) and it is transparent by default so that AppStore compatibility isn't jeopardised. My idea has always been to test and tune my patch in the wild and then present it again with community back-up.
There has also been an exchange with someone from the MSWin universe about linking this patch to to-be-developed qt.conf functionality, e.g. to replace the XDG_DATA_DIRS env. variable or possibly even the option to define all (alternative) QSP locations via qt.conf .

>2. There may be a concern about side-effects, as the behavior of Qt
>will depend on an environment variable where it did not before, with
>_potential_ interaction between separate installations.

The env. variable is not required, it was added to conform with the behaviour on other Unix variants but I never use it myself.
XDG_DATA_DIRS is not an env. variable that is used by other Mac software, but it shouldn't be that hard to find an alternative for it should that be necessary.

>3. Will also need some "cooperation" from the calling app in order to
>work for all installation scenarios (XDG_DATA_DIRS will have to be
>set/adjusted, and an extra setup call may be needed to request
>"Unix-behavior" from QStandardPaths).

No, you only need to set a preprocessor token or two during compilation. That is something that could easily be handled via the ECM.


>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. The goal is to provide the best and easiest way to run generic Unix applications as if you were working on a Unix workstation (wait, Macs actually are Unix workstations, too).
This includes interoperability with GTk/Gnome applications and anything else that follows the XDG/FreeDesktop standards and thus need to find certain resources in well-defined locations if they are to know about KF5 applications, and vice-versa(e.g. : open an SVG in Inkscape from a KF5 app or a text file in Kate from a GTk/Gnome app).

>As one drawback I can think of, handling supporting binaries, e.g. in
>"libexec" may cause a headache, although this, too should probably be
>solvable by appropriate adjustments of the installation layout or
>symlinks.

"libexec" and the Qt5/KF5 plugins directory could go into /Library/Application Support/KF5 for instance. I'd strongly advise against symlinks, unless they're all pointing to central locations. And not for libraries; the Mac linker will store normalised paths to shared libraries.

>As, so far, qt.conf does not affect QStandardPaths at all, however,
>such a patch would probably be rather intrusive in itself. (Also, so
>far, qt.conf only support one path per type, not a list of paths).

Patch size is not a problem at least if the patch is potentially upstreamable. The problem I see with qt.conf is that it is application-specific; each app bundle will have to provide its own copy.


>Ok, sorry for the long mail. Long story short: We need to come up with
>a solution, and it best be a solution that
>a) can be upstreamed to Qt
>b) works out for MacPorts, Homebrew, _and_ Craft.
>So does any of the approaches outlined above qualify for these
>conditions, or what else could be a viable route to take?

I've had enough time to muse over this to be sufficiently certain that my QSP patch would be the way to go if we're talking about upstreaming a patch to that class.

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. In my eyes that could lead ultimately to a CMake build option that will enable a standalone app bundle build when building on Mac (or disable it if the default though that should probably be project-specific; I believe something like KDE PIM cannot be bundled that way for instance).
I'd be willing to participate in such an effort though mostly to guarantee that "linuxy builds" will continue to work because I have no interest in or use for standalone bundled versions myself.

As to "our own kde-mac" people: nowadays that seems to be just me ... and it's very likely that I will drop out too when my current Mac dies or becomes too slow.

R.