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

[René J.V. Bertin]

On Sunday January 04 2015 21:09:18 David Faure wrote:

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

Erm, KF5 stands for KDE Frameworks, no? And KDE?

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

I still don't think I agree: a Desktop Environment isn't made by 1 application, but by a set of applications sharing similar design and building on shared, base functionality etc. Whether you want to call it a Desktop or Plasma or a User Experience Framework is just semantics, though.

And let's be clear: use OS X users were never interested in the KDE Desktop per se, as we already have our environment that we cannot dish. 

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

Really? You can run any among those applications without the "frameworks" being present? O:-)

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

Like it or not, I think many people (including me) will continue to think of KF5 as KDE 5. If not only KDE just sounds better than KF5...

> 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 

I doubt that, unless the KF5 frameworks shrink to something of no interest outside of for instance Plasma environments or in any case without interest for the application in question.
As long as they (KF5) do, the reason their (apps) dual versions exist is to allow them (apps) to be installed without imposing additional frameworks a user might not want, or that might not exist for his system.

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

Yes, and this is something where we're quite likely to run into other issues, I'm afraid. With KDE4 we've been able to patch many things in descendants of Qt classes, which makes it possible to do things that could interfere with pure Qt apps. That will no longer be possible were the KDE classes in question were integrated into Qt, which AFAIK was done without feedback from KDE-Mac users (most of the few of whom were probably unaware of what was going on) and possibly even before we got KDE4/Mac to the point where it currently is.

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

I hope my remarks directly above and a bit below make this a bit clearer..

An example: KDE4 menu titles. IIRC they're called menu sections in Qt5, and they are supposed to work through a texted separator. While that will work in floating and widget-attached menus, it doesn't in the toplevel menubar: the text is not rendered because the OS has no support for this. In KDE4, the extra rendering often crashed the application when it was done in the menubar, until I patched KMenu. Fixing the Qt5 menu section issue will require fixing Qt5.
That's an example where your argument "there are no more KDE apps" applies, because adding menu sections is no longer a KDE privilege, so if it still doesn't work in Qt5.4 there's a good reason to fix it without need for a "KF5-on-Mac specific patch".
Menu item placement is another thing, though. I continue to think that Qt has a design bug by using text-based heuristics to decide which actions become the About, Preferences, Quit, etc. menu items, a number of which end up in a different menu than the one where the application thinks it's putting them. It seems however to work fine for the majority of (commercial?) Qt apps, or Digia would have changed their approach already. Not so for KDE apps (sorry...), some of which end up with a completely unrelated action under (and called!) the Preferences menu item. The only ways to address this is either to change all KDE apps to set an explicit menuRole for each action they create, or to patch Qt.

> Patching Qt5 doesn't sound like a good solution to me, in any case.

See above. I've accumulated a number of other general patches over time for things that appear to be issues only for KDE apps (e.g. the file watcher class printing out a warning that it couldn't add another file, which is triggered mostly and a lot by KDevelop). Ian already mentioned raster rendering mode: this mode could be forced in kdelibs4 to prevent rendering issues that don't occur with pure Qt apps. Maybe such a patch is no longer required with Qt5, but maybe we'll have to find a place to force a specific rendering mode, and if that cannot be done in KF5 it'll have to be in Qt5 (or in each individual KF5 client app). And that would be a case where Qt (= functions in the Qt API) should know if the application they serve will also use KF5 features, so that things can be set up appropriately.

> > > So let's forget about "KDE apps", please. This is about making QSP work
> > > with the MacPorts directory layout.

True, this particular thread is about QSP :)


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

I meant configuration files under /etc/xdg that point to, well, additional locations to find configuration files and the like.

> Err... so 
> FSFindFolder(kUserDomain, kOnAppropriateDisk, false, &ref) does not return a 
> shared location? Are you sure? I was pretty sure it returned 

No, it's the kind of function I've never used (and we have access to the same online API documentation so I trust your understanding of what it's supposed to return).

> /Library/Application Support, which surely is shared.

Yes, but only in the sense that it holds the folders for individual applications' default settings and stuff. It does not hold folders containing all .desktop files, or (icon) themes that are read by every application that wants to.

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

No. It can, but it's not expected to. MacPorts is self-contained exactly to have a homogeneous environment providing all dependencies except for the system libraries (in any case the ones not available in often more recent FOSS form and version) and the build toolchain (though you can install compilers). 

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

What do you mean with "any use of a KF5 library"?

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

It might be needed for KF5 apps on OS X, independent of whether KF5 and Qt5 are installed through MacPorts, for reasons outlined above.
And it'd probably be in QtGui too, in that case.

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

No, as I said MacPorts only supports dependencies through itself. It'll even install XOrg, python and a number of other things also provided by through the OS, to avoid installing things outside its prefix and to be sure a recent enough version is installed without possible Apple patches that could interfere. (And of course with the possibility of applying patches of its own :))

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

Indeed, but there should be CoreFoundation functions for retrieving the location of the bundle in lieu of a ${prefix}.
Anyway, far from me to propose this in place of a MacPorts-based approach! (Even if I did once fool around creating a monolithic FFMpeg framework with headers and all from the stuff installed through MacPorts ... as a proof of concept :))

R.