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

[René J.V. Bertin]

On Sunday January 04 2015 16:35:09 Ian Wadham wrote:
> René has had direct experience with Info.plist files, so I expect he knows
> how to get the above ideas to work in real code.

The keys/values in the Info.plist are handled on a case-by-case basis in my experience. Some are presumably read out by code that gets executed regardless of how you start the application (which would fit with the old rule-of-thumb that GUI apps need[ed] to be in app bundles and started with the full path), others apparently only when starting an app via LaunchServices (NSLaunch) and of course one can add dedicated keys that have no meaning at all.
So, yes, it's perfectly possible to set XDG related variables that describe the local install configuration in an Info.plist key, but it will probably still have to be read explicitly if Qt doesn't (like it does with the LSUIElement key) and it will work only with applications that reside in an app bundle (see my patches to kglobalaccel and other utilities that should run as an "agent").

> It may be that the LSEnvironment property in Info.plist does not work any more
> in the version of OS X I have (10.7.5 Lion), but it is odd that Apple's GarageBand,
> iMovie and iTunes apps all have LSEnvironment values in their Info.plist files.
> Otherwise I would not have tried using LSEnvironment.

Those are older apps (some now discontinued) that also support OS X 10.6 ... and it's simply possible that the Info.plist templates were never pruned of obsolete keys!

> What is the situation with those apps' Info.plists in Mavericks and Yosemite?

iTunes 11.22 still has the key, but it's not the latest version...

> The Linux way for binary packages is to install them into a standard path
> that doesn't require env vars (/usr), and my patch was trying to do the
> same by using /opt/local as such a standard path. But since MacPorts
> apparently offers

Yes, MacPorts can be installed anywhere if you're willing to have it build every single port from source.
Your patch can be adapted easily enough; it's standard practice for ports to patch files with a placeholder, and then use Tcl file processing routines to replace that placeholder with the prefix.
To keep it readable and functional without the Tcl phase, I use //opt//local// as the placeholder (to be replaced by /opt/local/ or /yourOwn/preFix/ ). Since OS X isn't ApolloOS/DomainOS, //opt//local// is equivalent to /opt/local ;)

> > c) There should be a way to get a KDE app to recognise itself as a
> > KDE app
> 
> I strongly disagree.
> One of the main goals of KF5 is to kill the distinction between a KDE app
> and
> a Qt app, especially from a technical point of view.
> 
> It's all Qt apps now.
> It's just that some apps use additional libraries.
> 
> If you take a Qt-only app and make it use one framework, does that make it a
> KDE app in your view? My answer: the question makes no sense, there is no
> such thing as a "KDE app" from a technical point of view.

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

The real question is more: what does it mean "to get a KDE app to recognise itself as a KDE app". 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.
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.

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

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

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

> A compile-time flag ... for Qt, or for apps?

Whatever works best...

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

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

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

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.

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) ^^

R.