[KDE/Mac] Thoughts on Qt5/KF5 on OS X

[René J.V. Bertin]

On Monday January 05 2015 12:37:22 René J.V. Bertin wrote:


> > I think it will never happen that Qt knows if the application it's running 
> > currently used KF5 libs as well.
> 
> We'll see to what extent that may turn out to be the only solution to yet-to-be-identified issues on OS X ...

Let me come back to this, expanding on the menu placement thing.

I discovered this issue when I first started using KDevelop. Back then, I quickly learned to avoid the KDevelop/Preferences menu item that's supposed to open the KDevelop settings dialog, because it would launch the selected project's cmake step. Turned out, the menu item activated KDevelop's Project/Configure Selection... action, which Qt put under the Preferences menu item simply because it's the 1st QAction created with a text matching something like `startswith "settings" OR "config" OR "preferences"`. KDevelop does create a "Configure KDevelop..." action later on, IIRC even through KStandardActions, but by then it's too late.
The same happens with the About menu (which would show the About KDevPlatform dialog instead of the About KDevelop dialog), but that's of course less serious.

The explanation is as follows. QActions are created with menuRole=TextHeuristicRole as a default. On all platforms but OS X that setting is equivalent to NoRole, meaning the actions are put wherever the application intends them to be put. Only on OS X does the code path when adding the action to a menu include a heuristics algorithm that compares the action text to a number of text patterns when it has that heuristic role, and changes the menu attribution when a match is found. This is done only when the target menu item isn't yet populated (rather, subsequent attemps don't overwrite the setting until the item has been "depopulated").
This has been implemented by Qt to allow Qt apps to get an OS X look-and-feel without requiring action from the developer, at least as long as there is no source for ambiguity like having multiple Configure or About actions. And I think I've already mentioned it: Qt developers who care about their apps behaviour on OS X can do what it takes to address any problems that arise in this aspect, either because they notice them themselves, or because they act on user feedback.

In kdelibs4, we can avoid the issue largely by forcing the menuRole to NoRole in the KAction ctor(s). That settles things for standard KDE apps (that use KStandardActions and KAction only) without interfering with pure Qt applications, but not for applications that also use QAction.
As I mentioned in my previous post, I have reported this as a bug in Qt4 and Qt5 asking for a way to deactivate at least the About and Preferences guessmatics, but the little feedback I got on those suggest that I need more weight behind me to convince the developer of the heuristics algorithm that it should be rethought. So I ended up deactivating part of the heuristics function in Qt.

I'm more than willing to think this over for Qt5/KF5 to address the issue. Basically, the mechanism seems to work correctly for Quit, and the additionals for Cut, Copy and Paste are there mostly for providing a keyboard shortcut when a file dialog is open. So as long as these actions have a text that translates to Quit, Copy, Cut, Paste there is little room for error (full string matching is used)
The About and Preferences cases are the problematic ones, and frankly I'm not sure I do not actually consider it the responsibility of the developer to either set these roles, or otherwise obtain an app that doesn't follow the platform tradition on OS X. Sadly I got the impression that Qt devs are not going to be very enthusiastic of making a change like this that "breaks" something for their clients...
In any case, I for one don't see an elegant and robust way to get an automatic search for the appropriate item to put under About and Preferences that works for KDE or KF5 apps and pure Qt apps alike.

Hence what I referred to earlier: Qt's heuristics function could be set up to disregard About and Preferences when an app is linked to specific KF5 libraries (kdeui equivalent?) and not otherwise. Alternatively there could be a Qt setting to deactivate those 2 components, but then that setting would ideally default to true when building KF5 apps on OS X, somehow.

> in your mind KDE5 includes a workspace and a whole set of apps.

No, I know I may have given that impression, but I'm aware it's not the case.

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

No, if I did you'd have seen me argue the futility of attempts to bring KF5 to OS X (short of porting back Qt5 to use XOrg/OS X :))

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

That really depends on the point of view you take. But granted, a good number of those KDE4 patches that actually correct Qt4 issues are indeed due to bugs in Qt: indeed:
> Why should something stay broken in Qt and be fixed/worked around in KDE
> code only?

Which takes us back to the chances we stand to get those corrected "upstream" ... because "they" won't necessarily think of our issues as something that's broken. In Apple's (in)famous last words on so many radar (bug) reports: "works as intended".

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

No, but it probably does mean it was never a serious issue. Spitting out a few warnings (cf. the file watcher issue) isn't an issue, but doing so for pages and pages can become a log pollution issue that's likely to be reported and fixed (this particular one should really be the equivalent of a kDebug instead of the qDebug it is).

This is an occasion to point out another OS X peculiarity: when started through the UI, an application's stdout and stderr are redirected not to a file like ~/.Xsession-errors or /dev/null if things are set up a bit better, but to the system.log . And I don't know of any way to change that except by a system-wide syslogd reconfiguration that would also suppress application output that *is* of potential interest.

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

No, I think that's not true. Of course the App Store's sandboxing rules do not impose every application to run off a separate partition or chroot. It also doesn't mean a text editor application isn't allowed to edit documents made with another text processing application.
AFAIK, it just means that applications are not supposed to read and write into the same settings directory. Unless it all plays at the level of the settings files, in which case indeed we have no problem at all. But that seems much harder to enforce, esp. since (again, AFAIK) it's not just limited to a single settings file.
So what I think is imposed is to have the settings file in ~/Library/Preferences/foo.bar.fooBarApp.plist and all other "private" stuff that doesn't correspond to the document concept in ~/Library/Application Support/fooBarApp/ 

It'll be easy enough though. Some Qt person (quite likely Thiago) will point out in no uncertain terms if a proposed patch would violate these holy rules. And then we'll see to what extent it would be possible to have the patch as a (non default) Qt build option.


> 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, that would be the most sensible thing to do...

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

As I already suggested or implied a number of times O:-)

R.