Qt5 : 5.9, 5.8 and Mac OS X 10.9

[RJVB (René Bertin)]

Not actually a ticket *with* an update, just about a (future) update:

Qt 5.9.0 LTS has been released and sadly but officially drops support for OS X 10.9 . Having already played with the RC version I can affirm that there are indeed issues with it, though I've been able to port the backend (QPA plugin) that does most of the platform-specific stuff to work on 10.9 by reintroducing code from 5.8.0 that was simply removed. I hope to be able to do the same thing for the rest of the code in Qtbase but it'll be a trial-and-error thing because there hasn't been a single upstream cleanup commit that would indicate where code has gone missing.

Anyway, that's something I'll attack when temperatures drop again here (or even after summer).

I'm mentioning this because we thus have to come to a consensus how to approach 10.9 support under the hypothesis that it will prove infeasible or undesirable to patch Qt 5.9 . Port:qt5 and family are still at Qt 5.7.1 which in my experience had more issues than Qt 5.8.0 (provided by my port:qt5-kde) that weren't compensated by any advantages over the newer version.

I think we should thus probably work towards providing a set of port:qt58* ports regardless of how my backporting efforts work out (and how long I still remain on 10.9.5 myself). It probably stands to reason to have an option to install the latest supported Qt5 version on 10.9 .

[ctreleaven (Craig Treleaven)]

It is already hard-enough to track down Qt-related issues on the Mac. We should keep our Qt ports as close to official distribution as possible. Thus if they drop 10.9 support, we should not even try to add it back.

IMHO, YMMV, etc

[mf2k (Frank Schima)]

Replying to ctreleaven:

It is already hard-enough to track down Qt-related issues on the Mac. We should keep our Qt ports as close to official distribution as possible. Thus if they drop 10.9 support, we should not even try to add it back.

I completely agree.

[michaelld (Michael Dickens)]

Agreed. Also: Keep the final version of the port around for its supported OS(es), so that folks on 10.9 can install -some- version of Qt5, which might (will hopefully) be good enough for the projects requiring Qt5.

[RJVB (René Bertin)]

Replying to ctreleaven:

It is already hard-enough to track down Qt-related issues on the Mac.

Is it? Maybe on newer OS versions...

[ctreleaven (Craig Treleaven)]

Replying to RJVB:

Replying to ctreleaven:

It is already hard-enough to track down Qt-related issues on the Mac.

Is it? Maybe on newer OS versions...

I'm not sure where you were going with your unfinished sentence but, yes, it is hard enough:

​https://github.com/macports/macports-ports/blob/master/multimedia/mythtv.28/files/patch-mythwidgets_osx_focus.diff

This trivial (4 line) patch represented a couple of days of researching and testing.

There are still some UI glitches in MythTV on Mac that apparently don't occur on Linux. All too often, the conversation goes like this:

Me: Myth on Mac does xxx. This is with Qt 5.y.

Upstream: Blah, blah. Are you using the official Qt distribution? If building locally, do you have any patches?

Me: Using MacPorts distribution with minimal patches.

Upstream: Oh, the problem is likely your patches. Prove the problem exists without them and maybe we can help.

So, yes, I vote that we stay as close to vanilla as possible.

Regarding 10.9 specifically, very, very few people have a compelling reason to NOT upgrade. Almost all the same hardware runs at least 10.10 and 10.11. It is not like when people really wanted to get a couple more years out of 10.6 so they could run some old PPC program. Let alone security updates.

[RJVB (René Bertin)]

Hmmm, I'm only talking about issues in Qt itself, almost anything else (in dependents) is mostly due to those dependents not testing on or considering specifics on Mac. It's rarely a big problem to prove that by using an official Qt install (cumbersome as that may be).

I also have spent uncounted hours figuring out things related to the Qt4 -> Qt5 transition. That was a huge change, but not a very good example in this context. Projects have had a LOT of time transitioning to Qt5 and since 5.7 Qt has been relatively stable.

But it's not a big secret that just using Qt means any software will run correctly on any of the supported platforms.

Then again I'm using a patched Qt version that has the very specific aim to improve things in this domain, notably the behaviour of KDE software on Mac. A few additional patches that bring back 10.9-specific code aren't going to make a big difference. I've already been running the backported Cocoa backend (and Mac widgetstyle, as far as I use it) for about 2 months. Remember, that code has been very well tested and isn't being removed because it's instable but rather as a bit of spring cleaning. Anyway, as indicated in my OP, I have no idea at this time how much of that cleaning has happened outside the Cocoa backend. The 5.9.0RC installer still worked on 10.9 and software built and ran until hitting one of the changes in the Cocoa backend.

I do have a compelling reason not to upgrade as long as I'm not obliged: getting things to work as *I* want has become increasingly cumbersome with each new OS X version and it's never the appropriate moment to take a few weeks off to figure out how to get back to a state where I'm feeling at home and productive. With 10.9 I actually ran it in a VM for months until I felt the time was right to transfer things to a regular boot disk, but then I had Parallels at my disposal which made it relatively easy to run an OS X VM. I'm trying to figure out how to clone my install to an external which I can boot in VirtualBox (so at least technically I can also run it on a Linux host) but I'm not making a lot of progress there.

Failure to backport Qt 5.9 will give me a lot more reason to upgrade.

[RJVB (René Bertin)]

Something I didn't think to mention, and that apparently didn't occur to anyone: patches to reintroduce 10.9 support are going to be specific to that OS version, one way or another.

Just to come back to that QComboBox example: I've never run into issues with that widget myself (AFAICR). But if it had been a frequent stumbling block for me and supposing nothing in its implementation has changed since the associated QTBUG report, I would have considered very seriously to apply the workaround patch to Qt.

Don't get me wrong, I'm not saying that it's a bad idea to have a "mostly stock" Qt5 port, but I think that is of interest mostly for ports of projects that know how to target Mac specifically. The primary MacPorts mission as far as I understand it is to provide an easy way to install open source projects on Mac - which most of the time means cross-platform projects not intentionally developed for Mac. Platform-specific changes to middlewares like Qt that impose patching most all dependent projects are better addressed by patching the middleware. That doesn't prevent anyone from raising the issue upstream (like you did with MythTV), but that's not our primary goal.

2 examples of the kind of patches I include in my port:qt5-kde: The patch of QStandardPaths: it allows to build code designed to locate shared resources in places ("standard locations") where they are found on Linux (e.g. under /usr/share) and where we also tend to install them in MacPorts ($prefix/share), without maintaining immense patch sets. It's done properly, so it remains possible to use only the Mac'ish standard locations. The patch of a QMenu hack: Qt has text-based heuristic guessmatics in place to infer which menu actions are to become the About, Quit and Preferences menu items in the Application menu. That works for applications with simple menus (as long as they are coded using more or less standard English), but things can go quite wrong. I've already had to deal with a case where the Preferences menu activated a non-interactive action with annoying and unintended effects. Now you can patch each dependent application to use QMenu::setMenuRole() on offending menu actions, but IMHO the more efficient fix for a context like MacPorts is to deactivate the offending heuristics hack (partly).

[chrstphrchvz (Christopher Chavez)]

Long term support for Qt 5.9 ended 2020-05. I suggest this proposal be abandoned, and for a minimum macOS version be set in qt59 to prevent building on earlier versions (edit: never mind, it is already set to require macOS 10.10 or later).

[Wowfunhappy (Jonathan)]

I have a Mavericks patch for QT 5.9 over here: ​https://trac.macports.org/ticket/62964. (If I'd seen this ticket earlier I would have added here instead, sorry.)

I agree that QT 5.8 should probably be the default on Mavericks. There are a handful of functions which I just commented out. None of the software I built seemed to care, but if something did, it would presumably fall over.

But, having QT 5.9 as an option makes it possible to build software for Mavericks which would otherwise just never work.

Edit: RJVB, it might be interesting to see your attempt too, in whatever state it was in. I just fussed around until QT built and then was surprised when everything seemed to work perfectly, or near enough.

[kencu (Ken)]

Jonathan, your happiness awaits <​https://github.com/RJVB/macstrop/blob/master/aqua/qt5-kde/Portfile>.

You will find that RJVB has an extremely extensive set of customized portfiles in his "macstrop" (MacPorts backwards) directory, and many of them are customized to 10.9, so you should like that -- kindred spirit.

RJVB knows a lot about how MacPorts works -- I would suspect that he most likely he knows as much as anyone on MacPorts knows, to be honest -- and can do things that most others would probably not attempt.

[RJVB (René Bertin)]

@kencu - please stop trying to make me blush ;)

WIth that off my heart: yep, my Qt 5.9 version is feature complete EXCEPT for QtWebEngine (which is simply too big to start digging into). Actually, my port:qt5-kde-devel even has a few backports from 10.10 but those will probably only be of use with certain of the other ports in my tree.

[Wowfunhappy (Jonathan)]

Oh wow, I wish I'd known about this earlier. I just installed and its great, miles better than my crappy attempt!

Any particular reason this never made it to the main tree?

(Are there any other awesome custom portfile repositories I should know about? I know about yours Ken!)

[kencu (Ken)]

Replying to Wowfunhappy:

Any particular reason this never made it to the main tree?

The upgrades he has are quite extensive and developed, and tend to be more "revolutionary" than "evolutionary". I think it's been hard for people to take on the responsibility for committing them and then handling any fallout that might then ensue.

And there is a certain degree of inertia is a situation where there is limited manpower, and "works well enough" seems better than "broken".

But it just takes a few champions as you have seen to make the needle move. It's not always logical.