[KDE/Mac] Thoughts on standard directories in Qt5 - QStandardPaths

[David Faure]

On Sunday 04 January 2015 19:11:08 René J.V. Bertin wrote:
> And I beg to differ. A KDE app is an application that makes use of features
> provided by the K Desktop Environment by using KDE libraries, making it
> part of that DE.

This isn't 1998 anymore. There is no "K Desktop Environment", but I'll 
translate what you meant by assuming you said "Plasma Workspace". And then I 
can disagree on more fundamental grounds than naming. The goal of KF5 is to 
let Qt-based apps use additional libraries WITHOUT this having any relation to 
the OS and desktop/workspace where the application runs.
Surely Scribus using Sonnet (to pick one random made-up example, but the same 
would apply with any Qt app and any KF5 framework) does not mean that Scribus 
has any particular ties with Plasma. It will still run just fine on Windows 
and Mac etc.
Using a KF5 library DOES NOT make an app "part of the desktop environment".
Anything that goes into that direction, undermines the whole idea of KF5.

> It has been explained to me that KDE was built atop of Qt
> just because it was convenient and most in line with the features sought,
> not in order to extend Qt (nor because of Qt's cross-platform nature).

This is true. So? Now the KDE community produces much more than a desktop, so 
this has evolved into: the KDE community provides three independent products, 
a set of libraries (the "frameworks"), a desktop (or "workspace"), and a set 
of applications. And you can use either of these independently from the 
others, that's the whole point of the separation.

> The real question is more: what does it mean "to get a KDE app to recognise
> itself as a KDE app". 

The whole point of my efforts on KF5 for the last 4 years have been, and I 
said it many times during presentations, that there is no longer such a thing 
as a "KDE app", from a technical point of view. At most this might mean an app 
produced by the KDE community, but technically the goal of KF5 is to provide 
the same features to apps produced by other people too, as long as they link 
to KF5 libraries.

> The majority of those already know that, because they
> were conceived that way. THose (like KDiff3) that can be built as pure Qt
> apps too probably have their own token that signals they're being built
> with or without KDE. 

You're still describing the kde3/kde4 situation. I certainly hope that with 
KF5, the apps don't need this dual compilation system, with or without kdelibs 
for kde integration. Marble's Qt Only and Calligra's Qt Only builds can 
hopefully go away now, because 1) we added a lot of things into Qt itself (so 
e.g. you no longer need kdelibs to get mimetype support, etc.).
2) the other things don't have the same dependency mess as before, things 
being much more modular.

Please, please, consider updating your view of the situation. We really really 
want to make it possible for any Qt-based application to use a framework, 
without requiring them to make huge changes: in kdelibs3 that was "you must 
use KApplication", in kdelibs4 that was "you need a KComponentData" (and a 
whole bunch of running daemons, for many things), with KF5 that should be "no 
problem, go ahead", not "ah, you need a patched Qt, or a special build flag 
for Qt, or a special file somewhere to make things work".

However for the issue of install dirs, I guess it's fine to say "if Qt and the 
app are both coming from MacPorts then the app will automatically find stuff 
in the right prefix" - which I guess means MacPorts giving Qt the paths to 
look into somehow. That's fine, app developers (and users) won't have to do 
any special setup.

> However, Ian might mean that it should be possible for
> Qt to know that an application is going to use KDE features, presumably so
> that KDE4 functionality that wasn't kept in KF5 could be introduced in the
> Qt equivalents. That's like patching a KF5-specific Qt5 build, but with
> runtime activation of those KF5 bits.

I have no idea what this really means, please elaborate.
Patching Qt5 doesn't sound like a good solution to me, in any case.

> > So let's forget about "KDE apps", please. This is about making QSP work
> > with the MacPorts directory layout. It will benefit "apps produced by the
> > KDE community", but not only these, from what I understand of the way
> > MacPorts works.
> 
> That's probably true, if not only because the patches made to port:qt4-mac
> are used by KDE4 and pure Qt apps alike.

Good. Then it is even more true with Qt5 and KF5.

> > If there's some sort of "registry" (.plist files or whatever the format
> > may
> > be) where MacPorts could write out the prefix(es) it's using to install
> > apps,
> > then QSP could read that and add theses prefixes to its search paths.
> 
> If somehow using such a registry is easier or more flexible that the
> alternative below, we can always agree on a location where this settings
> file might be kept. A bit like how qtchooser works, but doesn't XDG already
> have something like that in /etc/xdg?

I'm not aware that XDG would have a set of install prefixes stored under 
/etc/xdg. The whole point of using different prefixes, on Linux/BSD, is to 
keep things separate. But that requires env vars :)

> > The alternative: Qt is documented to find stuff in the default MacPorts
> > prefix (/opt/local) automatically, advanced users who want to use another
> > path have to set XDG_* env vars.
> 
> Again this would have to be something that's selected at Qt build time, or
> at application build time. Reading settings from a shared location is
> apparently incompatible with Apple's Mac App Store rules ... and anything
> that violates those rules won't be accepted in Qt.

Err... so 
FSFindFolder(kUserDomain, kOnAppropriateDisk, false, &ref) does not return a 
shared location? Are you sure? I was pretty sure it returned 
/Library/Application Support, which surely is shared.
That's what QSP looks into. So I think this argument doesn't hold, since QSP 
is already doing exactly this. Adding another path doesn't change much.

> > For Qt would be a very bad idea, unless it's customary to install Qt twice
> > on
> > the system, once in a proper Mac OSX location and once in a MacPorts
> > location? If that's not how people do this, and a single Qt is used, then
> > a
> > compile-time flag for Qt can't work.
> 
> I wouldn't be amazed if many people had multiple Qt installations, say at
> least one from MacPorts (which you'll get if you install a port depending
> on Qt because MacPorts is self-contained) and one from a Trolltech or Digia
> installer. Plus of course the various installs in self-contained app
> bundles (VirtualBox and Parallels Desktop both contain a rather complete Qt
> library, for example).

Sure. The question is whether an app from MacPorts should be able to work with 
a Qt from elsewhere. Should it? (I have no idea)

> > For apps ...well, I don't see how that flag would affect the behavior of
> > QStandardPaths. Unless you add code to every app that uses a framework,
> > but
> > then it's about adding some code in main() (bad idea, not modular!), not a
> > compile-time flag (-Dsomething).
> 
> QApplication.h could well contain a static function or additional inline
> QApplication member functions that appear only when the compile-flag is
> defined, and that get executed before the payload of the regular ctor.

If this is necessary for any use of a KF5 library, then it would be too much 
of a requirement on apps, as said above.

If however this is something that is only needed in MacPorts and that all 
MacPorts apps automatically get somehow, then why not (should be in QtCore 
though).

> > His idea is using the library/framework's disk location (if that can
> > be determined at runtime) to get a relative path for other xdg-like
> > locations. For example if an application that is using sonnet which is in
> 
> Doesn't even have to be a runtime evaluation, certainly not if we're talking
> about linked-in frameworks/libraries (OS X hard-codes the
> normalised/expanded path to a library, though fortunately not to the level
> of the foo.major.minor.patchlevel.dylib version). The build system can then
> extract ${prefix} (which it already knows) and use it to hard-code certain
> path constants, completely in line with traditional Unix practice.

But that doesn't help if it should be possible to have Qt in a certain prefix, 
and apps in another prefix. Then Qt can't know about the app prefix.
Is this supported with MacPorts, though?

> NB: we need to be careful with the term frameworks; on OS X those are first
> and foremost the standalone shared library bundles, possibly with other
> libraries embedded in them, as well as the corresponding header files and
> sometimes even related executables.

Right - whenever *I* say framework, I mean that in the KF5 sense, not in the 
OSX sense :-)

> Which reminds me that we could be following a radically different approach
> in which all of Qt5 and all of KDE 5 Frameworks live in 2 respective
> .framework bundles (each under ${prefix}/Library/Frameworks for MacPorts,
> of course) ^^

You'd still need to be able to find data files in there somehow...

-- 
David Faure, faure at kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5