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

List:       kde-mac
Subject:    Re: QStandardPaths::GenericDataLocation on MacOS
From:       René_J.V. Bertin <rjvbertin () gmail ! com>
Date:       2018-05-03 9:24:51
Message-ID: 2352169.50QV1EAVtl () bola
[Download RAW message or body]

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.


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