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

[David Faure]

[Mario answered parts of this email very well, I won't repeat what he said]

On Sunday 04 January 2015 22:22:09 René J.V. Bertin wrote:
> > 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:-)

There are layers. Apps and workspace depend on frameworks, but frameworks 
doesn't depend on anything else (just Qt).

> > 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 mixing two things. KF5 is *just a set of libraries*.
You can't possibly be thinking of this as KDE5, since in your mind KDE5 
includes a workspace and a whole set of apps.

KF5 is not that. It's just 62 frameworks on top of Qt. You can't "run KF5",
you can't "show KF5 to your friends" or make a screenshot of it.

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

If you think the KDE Frameworks are not useful outside Plasma environments, 
you are very wrong, and I can say so because I have proof.

1) I'm visiting a commercial customer next week who is going to use KIOCore in 
an embedded linux product

2) I know of two other commercial entities using KArchive, plus a lot of 
interest from the Qt mailing-lists

3) the RazorQt guys have expressed a LOT of interest in the KF5 libraries.
That's competition to Plasma, if you wish. Surely this proves that KF5 is 
useful outside of Plasma. They need network transparency and file-manager 
building blocks, they need window-system integration classes etc. etc.

And this is just the beginning, the frameworks have only been out for 6 
months. We are going to see more and more of that.

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

So you'll have to do things right, instead. I consider that a good thing :-)

> [...]
> Fixing the Qt5 menu section issue will require fixing Qt5. 
> [...]

Good, then (let's) fix Qt 5 :-)

Why should something stay broken in Qt and be fixed/worked around in KDE code 
only?

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

Most actions are created by KStandardAction, though, so you can already start 
there.

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

If it's a Qt bug, it's a Qt bug.

The fact that you only see it from KDE apps doesn't mean that it doesn't 
affect other apps.

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

I know, and I don't think this exists, at the XDG level.

You must be thinking of kde(4)rc.

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

Possibly. So? If a shared path allowed, it's allowed, whether it's called
/Library or /opt/local ...

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

OK. Then there's a short term option which is to finish the QStandardPaths 
patch and apply it only the MacPorts build, until it's proven to work and can 
then be submitted to Qt upstream.

(Of course doing that offers an additional possibility: patching the install 
prefix into Qt at install time, so that setting env vars isn't needed)

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

Any application using 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.

Again, think of a pure-Qt app installed via MacPorts, and installing into 
${prefix}/share. QSP should be able to find stuff there. That's unrelated to 
KF5. Something missing in Qt, let's fix Qt.

> And it'd probably be in QtGui too, in that case.

No, QStandardPaths is in QtCore, it should work the same in non-gui apps and 
in gui apps.

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

I think you misunderstood my question, which I'll rephrase:
for a MacPorts user, is it possible to install Qt into /opt/local and install 
an app (still via MacPorts) into /opt/myapp or, say, $HOME/myapp ?

(and if so, does it all work automatically without setting env vars?)
(the question is about MacPorts in general, not KDE specific)

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