qt4-mac : set the graphicssystem via qtconfig

[RJVB (René Bertin)]

There has been some discussion concerning flickering UI elements under OS 10.14 in KDE4 applications leading to ​https://github.com/macports/macports-ports/pull/2974 . KDE4 has long forced raster mode for a variety of reasons, but apparently it causes or aggravates the flickering graphics problems under 10.14 .

The pull request mentioned above simply removes the forced raster mode indiscriminately, i.e. also on OS versions where it is to be preferred.

I've implemented an alternative where users can control the default graphics system used (native vs. raster vs. OpenGL) via Qt's own qtconfig utility (to be used with a modified patch to kdelibs4). I've set the default to "Native", evidently.

I would have preferred a solution specific to KDE4 but achieving a similar user-friendliness would require a lot more work. It should be possible however to implement a setting controlled through qtconfig but used (applied) only by kdelibs4 (in the KApplication class).

[RJVB (René Bertin)]

Replying to RJVB:

It should be possible however to implement a setting controlled through qtconfig but used (applied) only by kdelibs4 (in the KApplication class).

I have a PoC but I'm not sure if it's that good of an idea to add an additional setting applying only to KDE apps in qtconfig. After all, raster mode became the default in Qt5.

The further tinkering did allow me to notice something else:

Setting raster mode as early as done by the attached patch appears to solve the graphics glitch when using the Oxygen or Breeze styles, where (menu) items would appear and disappear when you move the mouse over their parent widget. It doesn't make sense to me, but it appears to be a fact.

[jjstickel (Jonathan Stickel)]

I updated the qt4-mac Portfile to apply this patch. It built and installed fine. What now? I can't find a qt4config utility.

[RJVB (René Bertin)]

Oh bugger, I didn't realise that port:qt4-mac doesn't patch the build system so it actually builds qtconfig ... I'm attaching an additional patch that does this.

Fortunately you don't need to rebuild Qt4 completely to get the utility, and you don't even have to apply the patch to the Portfile.

In case you let port clean the build directory:

> port -n patch qt4-mac [+your+variants+of+choice]

then create a build directory somewhere, chdir into it and then

> qmake `port work qt4-mac`/qt-everywhere-opensource-src-4.8.7/tools/qtconfig/qtconfig.pro
> make

I'm guessing you'll find qmake in /opt/local/libexec/qt4/bin . After the build you'll have a new qtconfig.app bundle which you can run as usual and move wherever you want. It's normal that it doesn't have a dedicated icon.

[RJVB (René Bertin)]

patch to build the qtconfig utility

[RJVB (René Bertin)]

Replying to RJVB:

After the build you'll have a new qtconfig.app bundle

NB: this will be put in /path/to/your-build-dir/../../bin . Keep that in mind, or change the DESTDIR line (to "./") in qtconfig.pro before calling qmake.

[michaelld (Michael Dickens)]

I'm pretty swamped right now & I doubt I'll get to this until December; just not enough time in the day! I'd be more likely to get to this if it were in a PR, but it's still going to take me a while given my workload through November -- so, please be patient & I will get there. A PR would allow you to more easily fix issues such as what the 2nd patch is doing, all without me having to lift a finger to deal with patching / reverting / whatever.

[michaelld (Michael Dickens)]

I have no objections to your patches per se, but I do want to verify building & runtime on various OSX versions before anything else.

[RJVB (René Bertin)]

Replying to michaelld:

A PR would allow you to more easily fix issues such as what the 2nd patch is doing

I'm not sure what you mean with that? If you mean the *other* patch I uploaded, it just removes the Mac from the list of platforms where qtconfig is NOT to be built. I have been using that one for years.

Qtconfig is a really simple and perfectly standard Qt4 application that should build on any platform where Qt4 builds itself. My initial patch doesn't change that. Patches have been developed on 10.9 and I have no reason to assume that Jonathan will report back that they don't work for him (they may not have the same effect on presence/absence of graphics glitches but that's another topic).

I didn't do a PR because I didn't think it necessary and didn't want to decide for you where and how you put the patchfiles into the Portfile. Now, if a PR means a CI will do those test builds on various OS versions then that changes things a bit...

[michaelld (Michael Dickens)]

I didn't do a PR because I didn't think it necessary and didn't want to decide for you where and how you put the patchfiles into the Portfile.

Understood. If you add the new patches to the end of the patches section with their own new (#) & explanation, that's perfectly find. I hope the patching MO in Qt4-mac is sufficiently clear to any experienced programmer to be able to follow suit.

Now, if a PR means a CI will do those test builds on various OS versions then that changes things a bit...

Yes, yes it does! YA reason for PRs! The MP PR system can be a little daunting, but if you try it out: go with the flow & don't worry too much about precision!

[RJVB (René Bertin)]

It's cumbersome above all, and macports-ports has a relatively huge git metadata overhead that is probably due to the fact it was converted from svn.

You may remember I have my own Qt4 port that was forked off yours, so I'm guessing I can still find my way around in yours (what with Qt4 being on life support and all that).

[jjstickel (Jonathan Stickel)]

Replying to RJVB:

Oh bugger, I didn't realise that port:qt4-mac doesn't patch the build system so it actually builds qtconfig ... I'm attaching an additional patch that does this.

I forgot to cc myself to this ticket, and so I just saw this now. I did let port clean my build, but that's OK. I'll just apply the patch and rebuild.

I can submit the PR once we are happy with this approach. I already modified the Portfile in the manner Michael suggests in comment:9.

[RJVB (René Bertin)]

Replying to jjstickel:

I forgot to cc myself to this ticket, and so I just saw this now.

That should happen automatically when you comment?!

I can submit the PR once we are happy with this approach. I already modified the Portfile in the manner Michael suggests in comment:9.

I was going to find a moment to do this but if you're up for it I'll gladly leave the honours to you :)

[jjstickel (Jonathan Stickel)]

Using qtconfig to change the raster setting (pull down menu titled "Default Graphics System") does not seem to affect behavior in Dolphin. When I closed qtconfig and clicked "yes" to save changes, my fonts got clobbered, so it is doing something. Also, "raster" and "native" work the same in qtconfig, but selecting "opengl" causes problems in that app but not in Dolphin.

[RJVB (René Bertin)]

Yes, qtconfig will also change the default system font back to what it considers the default on your platform (and careful with Qt4 if you use a less common font weight like "Medium"). It's always a good idea with that tool to check the fonts setting before saving.

Anyway, it sounds as if maybe you didn't apply the companion patch I appended to your PR. Because if your KApplication class still forces a specific mode you won't see any effect from the setting made in QtConfig which is applied at an earlier moment. The absence of effect of picking OpenGL mode is telling, so I'm guessing that any other pure Qt4 app will be affected in your case, and no KDE4 app.

If not, than we'll have to figure out why you don't see any effect in KDE4 apps, which is going to write some KDE4 code (there's no easy API for querying the current graphics system).

[jjstickel (Jonathan Stickel)]

Replying to RJVB:

Anyway, it sounds as if maybe you didn't apply the companion patch I appended to your PR.

That's right, I didn't do that because it wasn't clear it needed to be done at the same time or where that patch would be applied. To kdelibs4?

[RJVB (René Bertin)]

Yes, that's an alternative version of the kapplication/raster patch to be applied instead of the original or the version from your PR. Sorry about the confusion.

[jjstickel (Jonathan Stickel)]

OK, it is working with the kapplication patch. No more dissapearing text in dialog boxes, even with raster. BUT kde apps crash for some themes, e.g., plastique, when using raster. QtCurve and aqua are OK. This is on MacOS 10.12.

[RJVB (René Bertin)]

When using raster? That's strange, because that's the same raster mode as they used before these changes, but I guess it's for the same reason why we no longer see graphics glitches in raster mode.

I can reproduce this on 10.9 and the crash is deep inside Qt's CoreGraphics code, interestingly also in qtconfig itself when I select the styles in question.

What are the other styles where this happens for you, CDE, "MS Windows 9x" and Motif?

I call Qt4 bug, worked around by using Native graphics if you really want to use one of these styles.

If I were to forward a wild guess I'd say that our previous way of setting raster mode, just a bit later, kept native mode on for a bit longer which allowed something crucial to be initialised.

We may need to document this, though.

[jjstickel (Jonathan Stickel)]

Yes, using raster as selected by qtconfig. I didn't test them all, but I had crashes with "MS Windows 9x" and Motif, I think. I'm fine with the using Native graphics as a workaround for those styles.

Document via note in the Portfile of qt4-mac or kdelibs4?

[RJVB (René Bertin)]

I suppose you are, you were planning to force Native graphics on everyone ;)

Maybe best to touch on it in the graphics system selector tooltip, and draw attention to the new feature via the port notes feature. I guess I'll be doing the PR for this after all!

[jjstickel (Jonathan Stickel)]

I captured the changes so far in a branch on my fork here:

​https://github.com/jjstickel/macports-ports/tree/qt4mac-raster

Maybe that is useful to you. It includes edits to the qt4-mac portfile. Note that I incremented the revision of qt4-mac and kdelibs4 for convenience for me when working on this. I'm not sure if that is correct to do for this fix.

[RJVB (René Bertin)]

@jjstickel: could you please try with the new kapplication raster patch I pasted (inline) into the PR (​https://github.com/macports/macports-ports/pull/3022#issuecomment-441384590)? This should

• prevent glitches when you don't change anything w.r.t. your current config (assuming you picked a graphics system via qtconfig)
• revert the glitches when you select "(unset)" in qtconfig

For anyone not following discussion on the PR: my initial proposal apparently caused crashing with more than just the incompatible styles that we identified. This version gives users the choice to stick with the forced raster mode as it was always imposed by port:kdelibs4 (and keep using pure Qt apps without imposing a graphics system choice). Or they can impose a choice via qtconfig.

[jjstickel (Jonathan Stickel)]

Replying to RJVB:

@jjstickel: could you please try with the new kapplication raster patch I pasted (inline) into the PR (​https://github.com/macports/macports-ports/pull/3022#issuecomment-441384590)?

I replaced the patch-kapplications-raster.diff with that one and rebuilt (and installed) kdelibs4. What functionality do you want me to try?

[RJVB (René Bertin)]

I thought that would be evident :) Check your graphics glitches (flickering):

• if you picked a graphics system via qtconfig this new version should not glitch any more than the previous version
• you should get the glitches again when you select "(unset)" in qtconfig

[jjstickel (Jonathan Stickel)]

Yes, OK, I didn't look for the (unset) option for graphics system. Selecting that reverts the behavior of kde apps to what it was before.

[RJVB (René Bertin)]

Thanks for the confirmation. That means we can now cater to all possibilities:

• reproduce the "legacy" behaviour (default graphics system for pure Qt4 apps, raster for KDE4 apps)
• impose native graphics on every Qt4 app
• impose raster graphics on every Qt4 app

[RJVB (René Bertin)]

In 8da4eb3dada6c3e790fab218cd9641db350e27a0/macports-ports (master):

qt4-mac/kdelibs4 : convert hardwired graphics system selection to use… (​https://github.com/macports/macports-ports/pull/3022)

• qt4-mac/kdelibs4 : convert hardwired graphics system selection to user option. Kdelibs4 used to set the Raster graphics system, causing graphics issues on newer OS versions. This change puts the graphics system under user control via Qt.

Closes: #57577