submission: port:qt5-kde

[RJVB (René Bertin)]

New spring, new ticket: I'm continuing the previous qt5-kde submission here, the old one (#48967) was getting too long.

port:qt5-qtbase & family are now at Qt 5.7.1, which is already obsolete: Qt 5.8.0 has been out and running on my systems for a few weeks now (in the form of "devel" version of the attached port:qt5-kde).

qt5-kde is still a Qt5 port that aims to make feature-full KF5 ports possible but that will work as a drop-in replacement for port:qt5-qtbase & family (drop-in to qt5-kde, in principle not back to port:qt5-qtbase as long as that standard Qt5 port remains at Qt 5.7). It also provides a qt5-kde-x11 subport which makes it possible to run Qt applications on remote X11 displays or use a Qt-based X11 terminal emulator (like Konsole5).

Given the number of patchfiles I'll continue to upload tarballs of the port directory; the port and its evolution can also be inspected on github:

​https://github.com/RJVB/macstrop/tree/master/aqua/qt5-kde

Please also note #53777 and #53778 for suggested (desired!) changes to the Qt5 PortGroups, allowing co-existence of the ports.

[RJVB (René Bertin)]

FWIW, Qt 5.7.1 has a number of known issues (e.g. with shortcuts) that have mostly been resolved in Qt 5.8.0; qt5-kde has patches (upstream or personal) for all 5.8.0 issues that I am aware of.

[yan12125 (Chih-Hsuan Yen)]

For easier cross-reference in the future, I added this ticket to KDEProblems.

[yan12125 (Chih-Hsuan Yen)]

A relevant Qt bug report: ​https://bugreports.qt.io/browse/QTBUG-62420, aiming supporting XDG-compliant standard paths for Qt on macOS.

[RJVB (René Bertin)]

I appreciate your interest. I thought I already added such a link to the wiki, along with instructions how to install my KF5 ports by adding a custom ports tree.

That's probably how far we'll get, since my co-maintainer disappeared.

[jjstickel (Jonathan Stickel)]

@RJVB, I'd really like to see KDE-5 (frameworks, or whatever it's called) on Macports master. KDE-4's obsolescence is showing. Some problems have workarounds, like those discussed on #57332. Other problems cannot be fixed. For example, some graphics packages no longer work because libkdcraw is not longer compatible with recent libraw (#56889).

How can I help? I have limited time but could do a little, especially testing. FWIW, Homebrew has KDE-Frameworks (​https://github.com/KDE-mac/homebrew-kde). I can try your ports tree, but I don't see that as a good solution except for power users.

[mojca (Mojca Miklavec)]

I cannot answer from René's perspective, but to us the biggest help would be submitting a set of clean pull requests (ideally with sufficient testing, but as long as the basics work, that's already a lot). Then Perry will make sure that someone reviews them (and will keep pestering everyone until the changes get cleaned up to sufficient extent to be ready for merging).

[RJVB (René Bertin)]

See, and that's just a dance I don't feel like dancing, not anymore, and not without commit rights myself. My Qt5 + KF5 tree has become, if I may say so, a monumental effort, it's written and works exactly the way I want it (esp. the KF5 ports, the qt5-kde port is a bit less clean). I don't want to have to justify and defend each and every way of doing things that looks as if it's non standard, each and every patch that isn't clearly addressing something needed for MacPorts and not suitable for upstreaming.

Note that there is a second repository, once maintained my Marko Känig which contains only the ports required for KF5 and which I keep up-to-date (when I think of it).

Evidently the goal used to be to incorporate these ports, one by one, before there were so many. I feel like that train has passed (several, even).

I can try your ports tree, but I don't see that as a good solution except for power users.

Recently I assisted someone who I think is the exact opposite of a power user. It was a bit of a trial and error procedure but in the end it worked for her (and my install instructions are better). I have been toying with the idea of writing a sort of installer but that's never been something with a high priority.

What also factors into this is the fact that I will almost certainly not replace my current Mac with another when it dies...

[barracuda156]

Replying to RJVB:

qt5-kde is still a Qt5 port that aims to make feature-full KF5 ports possible but that will work as a drop-in replacement for port:qt5-qtbase & family (drop-in to qt5-kde, in principle not back to port:qt5-qtbase as long as that standard Qt5 port remains at Qt 5.7). It also provides a qt5-kde-x11 subport which makes it possible to run Qt applications on remote X11 displays or use a Qt-based X11 terminal emulator (like Konsole5).

Do you think it may work to build Qt5 on macOS with Cocoa disabled and X11 used instead? It could allow having newer Qt on older systems.

(Other option would be to restore Carbon, but it may be rather bothersome if at all realistically doable.)

[RJVB (René Bertin)]

Not building the Cocoa QPA would solve a number of backwards compatibility issues but not all. The platform QPA is only for the GUI but Qt contains a lot of other platform-specific code. Most but not all of that is in QtBase; QtQML must have a bunch of it too. And then there's the QtWebengine component which comes with its own OS-version limitations.

I did manage to backport Qt 5.9 to OS X 10.9 (and even backport a few Qt 5.10 classes, and didn't bother with QtWebengine). Most of that was simply by re-introducing "outdated" code that was removed, with #ifdefs. Earlier versions of my qt5-kde ports (in my MacStrop repo) will support earlier OS versions as per Qt standards; it looks like I got the first functioning X11 subport with Qt 5.5.0 (but evidently it kept evolving!).

As you probably saw, the qt5-kde-x11 subport builds the qtbase and qtx11extras components but throws out all things already installed by the main subport in its post-destroot phase. Transfer the subport-specific dependencies, patches and configuration arguments to the main subport and it will do an X11 build (remember to disable the qtmacextras component). I have never verified this but I assume that the other subports will just build as normal.

FWIW, the Qt policy (for v5) has always been that they supported all QPAs that could be built and would function on a given platform so a patch set to get an X11 version to build that adhered to their standards would in principle have been accepted. I've had a ticket open about that but never found the courage (nor time) to jump through all the hoops.