#5 patch for building on OS X (MacPorts)

[R.J.V. Bertin]

Attached is a patch that enables building on OS X. Everything seems to work except

• the theme cannot be used in pure Qt applications, probably due to a bug in QWidget::setMask (all rounded corners have black rectangles superposed)
• the blurring in inactive text/widgets looks horrible
• the title text of dock windows with vertical titlebars is not rotated but printed within the titlebar's width instead (i.e. "extreme overstrike").
• The presets dialog has 2 entries at startup that cannot be deleted and carrying names that hint at a null pointer dereference or some similar bug.

[Thomas Luebking]

Sorry for the delay and thanks for the patch.

Two questions:
- does "find_package(X11)" actually cause any trouble on OSX?
- why do you seek to disable ARGB support on OSX by default? Is it broken? (thus should be fixed or the option fixed to "OFF")

On the comments:
- all rounded corners have black rectangles superposed
This should be no problem is ARGB windows are enabled, since the window is then not masked but the corners are just transparent (and antialiased)

• the blurring in inactive text
  It's not really blurred - the text is painted several times (this is legacy behavior. Painting texts on images, blurring and then esp. uploading the image to the X11 server over and over again would have been quite some overhead before the raster graphicssystem was introduced (iirc 4.6) or turned default (4.8)
  Since Bespin is EOL, that won't change, but there's a "hidden" config key to change the appearance of disabled text in general:
  StrikeDisabled=true

• the title text of dock windows with vertical titlebars
  The entire docktitle is not aware of the vertical character (since I was not aware that the feature exists ;-)
  -> gonna fix

• The presets dialog has 2 entries at startup
  Can you please provide a screenshot (and/or entry strings)?

[R.J.V. Bertin]

On Friday October 10 2014 20:10:05 Thomas Luebking wrote:

Sorry for the delay and thanks for the patch.

Two questions:
- does "find_package(X11)" actually cause any trouble on OSX?

It might, because most of us (using FOSS via MacPorts or otherwise) will have X11 installed, so its presence cannot be taken as an indication that the build should be for X11.

• why do you seek to disable ARGB support on OSX by default? Is it broken? (thus should be fixed or the option fixed to "OFF")

Compositing is broken in Qt; the Oxygen and Breeze styles suffer from that too. And that's even with Qt forced to raster rendering.
But to be honest, I simply removed support for translucent windows because I have no use for those esp. when I see a remark about performance suffering (apart from coupling opacity to a moderator+scrollwheel to peek behind a window without moving/minimising it, but I doubt that'd work on OS X).

EDIT: I was right in doubting this'd work: the ARGB code invokes X11 functionality.

On the comments:
- all rounded corners have black rectangles superposed
This should be no problem is ARGB windows are enabled, since the window is then not masked but the corners are just transparent (and antialiased)

Yes, and somehow this works in KDE but not in pure Qt applications, even without those translucent windows...

Since Bespin is EOL, that won't change, but there's a "hidden" config key to change the appearance of disabled text in general:
StrikeDisabled=true

Good to know - where/how do I set it?

• the title text of dock windows with vertical titlebars
  The entire docktitle is not aware of the vertical character (since I was not aware that the feature exists ;-)
  -> gonna fix

Heh, guess that proves you don't use KDevelop

• The presets dialog has 2 entries at startup
  Can you please provide a screenshot (and/or entry strings)?

I'll post a screenshot, and an export of one of the entries.

BTW, I know it's off-topic, but here's a strange backtrace - a null *this pointer, that should never happen, right?

Application: KDevelop (kdevelop), signal: Segmentation fault
[KCrash Handler]
#4  QWidgetPrivate::createExtra (this=0x0) at kernel/qwidget.cpp:1783
#5  0x0000000102197c7a in qobject_cast<QStyleSheetStyle*> [inlined] ()
    at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.6/src/corelib/kernel/qobject.h:2673
#6  0x0000000102197c7a in QWidget::setStyleSheet (this=0x13ae4db60, styleSheet=@0x7fff5fbfc6a8) at kernel/qwidget.cpp:2675
#7  0x000000011f98d62a in Bespin::Hacks::removeStyleSheet (this=0x0, w=<value temporarily unavailable, due to optimizations>)
    at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_bespin/bespin/work/cloudcity-code/hacks.cpp:709
#8  0x00000001032ce461 in QObjectPrivate::resetCurrentSender ()
    at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_aqua_qt4-mac/qt4-mac/work/qt-everywhere-opensource-src-4.8.6/src/corelib/kernel/qobject_p.h:1222
#9  0x00000001032ce461 in QObject::event (this=0x1326b4100, e=<value temporarily unavailable, due to optimizations>) at kernel/qobject.cpp:1228
#10 0x000000010214c0fd in QApplicationPrivate::notify_helper (this=0x108cbd0f0, receiver=0x1326b4100, e=0x1320c6bc0) at kernel/qapplication.cpp:4565
#11 0x000000010215317e in QApplication::notify (this=0x7fff5fbfe480, receiver=<value temporarily unavailable, due to optimizations>, e=0x1320c6bc0) at kernel/qapplication.cpp:3947
#12 0x0000000101a5ee97 in KApplication::notify (this=0x7fff5fbfe480, receiver=0x1326b4100, event=0x1320c6bc0)
    at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdelibs4/kdelibs4/work/kdelibs4-4.14.1/kdeui/kernel/kapplication.cpp:321
#13 0x00000001032b9cac in QCoreApplication::notifyInternal (this=0x7fff5fbfe480, receiver=0x1326b4100, event=0x1320c6bc0) at kernel/qcoreapplication.cpp:953
#14 0x00000001032bb260 in QCoreApplicationPrivate::sendPostedEvents (receiver=0x0, event_type=0, data=0x108e00b60) at kernel/qcoreapplication.cpp:1577
#15 0x00007fff804393d1 in __CFRunLoopDoSources0 ()
#16 0x00007fff804375c9 in __CFRunLoopRun ()
#17 0x00007fff80436d8f in CFRunLoopRunSpecific ()
#18 0x00007fff881e67ee in RunCurrentEventLoopInMode ()
#19 0x00007fff881e65f3 in ReceiveNextEventCommon ()
#20 0x00007fff881e64ac in BlockUntilNextEventMatchingListInMode ()
#21 0x00007fff825d1eb2 in _DPSNextEvent ()
#22 0x00007fff825d1801 in -[NSApplication nextEventMatchingMask:untilDate:inMode:dequeue:] ()
#23 0x00007fff8259768f in -[NSApplication run] ()
#24 0x00000001021058a8 in QEventDispatcherMac::processEvents ()
#25 0x00000001032b8bc4 in QEventLoop::processEvents (this=<value temporarily unavailable, due to optimizations>, flags=@0x7fff5fbfe1e0) at kernel/qeventloop.cpp:149
#26 0x00000001032b8f74 in QEventLoop::exec (this=0x7fff5fbfe230, flags=@0x7fff5fbfe240) at kernel/qeventloop.cpp:204
#27 0x00000001032bb7ec in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225
#28 0x00000001000148b4 in main (argc=1606411264, argv=<value temporarily unavailable, due to optimizations>)
    at /Volumes/Debian/MP6/var/macports/build/_Volumes_Debian_MP6_site-ports_kde_kdevelop-git/kdevelop-git/work/kdevelop-git-4.7.60/app/main.cpp:564

[Thomas Luebking]

EDIT: I was right in doubting this'd work: the ARGB code invokes X11 functionality.
That would be a bug - do you have a compile error for me?

Compositing is broken in Qt; the Oxygen and Breeze styles suffer from that too. And that's even with Qt forced to raster rendering.
Does this refer to "Screen shot 2014-10-11 at 00.25.27.png"? (That's not a compositing error)

Yes, and somehow this works in KDE but not in pure Qt applications, even without those translucent windows...
The behaviour is bound to whether the popup is set to a 32bit window - whether that happens from some KDE lib (plasma?) or because Bespin set it doesn't matter.

You may try polish.cpp:525
- #if BESPIN_ARGB_WINDOWS
+ #if 1

Good to know - where/how do I set it?

bespin write style StrikeDisabled true

This adds the key to the [Style] section (~/.config/Bespin/Style.conf)

Heh, guess that proves you don't use KDevelop
No - prefer "slim"/"metal" solutions like kate (with terminal where i call make/gcc ;-)

I'll post a screenshot, and an export of one of the entries.
That's indeed odd. Those do as well show up when you move away ~/.config/Bespin/Store.conf?
(I'll mail you a debug patch in case - either QMap or QSettings is buggy in this (empty) case.)

here's a strange backtrace - a null *this pointer
Qt delivers an event for a posted message (slot invocation in next event cycle) to a NULL object - that should not happen, no.
Also, the object is instanciated right before posting the message and released when the application gets unpolished, what means:
To run into this itfp, a KMessageWidget must be added and right afterwards the Application be unpolished (eg. for a style change) -> how did you trigger this?

[R.J.V. Bertin]

On Saturday October 11 2014 12:15:47 Thomas Luebking wrote:

EDIT: I was right in doubting this'd work: the ARGB code invokes X11 functionality.
That would be a bug - do you have a compile error for me?

Well, damn if it doesn't build fine now... I'm sure that the error I got led me to a section where translucency was obtained with a number of calls to XProperty.

Compositing is broken in Qt; the Oxygen and Breeze styles suffer from that too. And that's even with Qt forced to raster rendering.
Does this refer to "Screen shot 2014-10-11 at 00.25.27.png"? (That's not a compositing error)

Yes, I does. How's that not a compositing error?

The behaviour is bound to whether the popup is set to a 32bit window - whether that happens from some KDE lib (plasma?) or because Bespin set it doesn't matter.

You may try polish.cpp:525
- #if BESPIN_ARGB_WINDOWS
+ #if 1

Tried that, and since ARGB mode apparently is possible after all, I tried that too. No luck...

This adds the key to the [Style] section (~/.config/Bespin/Style.conf)

I just set the default to True on OS X ;)

That's indeed odd. Those do as well show up when you move away ~/.config/Bespin/Store.conf?
(I'll mail you a debug patch in case - either QMap or QSettings is buggy in this (empty) case.)

QSettings are stored in a very different manner on OS X, all together in a big com.trolltech plist. Which means I can't throw away Store.conf. But that isn't actually necessary. I never had Bespin on my system before, and those entries were there the very 1st time I started the bespin application. They also come back when I delete them.

To run into this itfp, a KMessageWidget must be added and right afterwards the Application be unpolished (eg. for a style change) -> how did you trigger this?

I had KDevelop running while I switched styles a couple of times. I think this crash happened when I quit KDevelop, possibly because it had retained the bespin style rather than changing to the new style. I'm sorry, this is very sloppy, I should have described the circumstances of the crash or not upload the trace at all :-/

René.

[Thomas Luebking]

Yes, I does. How's that not a compositing error?
Well, it /is/ a compositing error, but in the Qt graphicssystem - this has not much to do with system compositing, ARGB windows and such. (Nor with setting masks)
This should really not happen with the raster graphicssystem (and since you say it doesn't happen for KDE clients, I believe this is actually the case)

Does it happen with "bespin demo -graphicssystem raster"?

I'm sorry, this is very sloppy
No need to be. If this is reproducible (and nasty) it's relatively simple to catch, but I fear it could point a general bug in Qt (or KDE or KDevelop in case they re-implement the event processing of QApplication) for delivering events to nullptr objects.

QSettings are stored in a very different manner on OS X
Ok, I'll send you a debug patch ;-)

[R.J.V. Bertin]

On Sunday October 12 2014 08:23:06 Thomas Luebking wrote:

Yes, I does. How's that not a compositing error?
Well, it /is/ a compositing error, but in the Qt graphicssystem - this has not much to do with system compositing, ARGB windows and such.

I wasn't claiming where the error was ;)
It's known that Qt's compositing is ... wonky on OS X.

Does it happen with "bespin demo -graphicssystem raster"?

Well, it does indeed NOT happen in qtconfig's preview when I launch it in raster mode!
I'm guessing that's a mode one has to select as early as possible, so it couldn't be done in the bespin code itself?

I'm sorry, this is very sloppy
No need to be. If this is reproducible (and nasty) it's relatively simple to catch

Of course. But that would mean I'd have to run the theme for a while. I don't think it'd be my definite choice, but I could do that out of altruism, now that the other issues have been addressed ;)

QSettings are stored in a very different manner on OS X
Ok, I'll send you a debug patch ;-)

Thx!

[Thomas Luebking]

so it couldn't be done in the bespin code itself?

Nope - has to be done before the QApplication constructor is called, what is always before the QStyle is loaded in all real-case scenarios.
When Bespin knows that it's in use, it's already too late. (Also you say other style are affected as well)

The order to determine the graphcissystem is:

the application commandline -graphicssystem switch
QApplication::setGraphicsSystem()
the QT_GRAPHICSSYSTEM environment variable
the Qt configure -graphicssystem switch

ie. if "QT_GRAPHICSSYSTEM=raster bespin demo" does not work, this means some Qt code really calls "setGraphicsSystem("native")" on OSX...
If it would work, this would only mean that the compile switch is chosen "badly" -> compile Qt with "-graphicssystem raster" and/or ensure to call "export QT_GRAPHICSSYSTEM=raster" in /etc/profile or similar.
(Ian and me actually had this topic somewhen in the past because the KDE Games apparently perform horrible on the native graphicssystem on OSX)

[R.J.V. Bertin]

Setting QT_GRAPHICSSYSTEM does work, so nobody does a "bad call". I do think that KDE has indeed been patched to set raster mode.

When I built Qt with raster mode on by default certain (pure Qt) applications I use started crashing, which they don't appear to do when using the env. variable.

Setting bespin through qtconfig with QT_GRAPHICSSYSTEM set to raster works, but when I relaunch qtconfig (or any other Qt app), the blocks are back. This does not apply to the Oxygen and Breeze themes. How weird is that??

What's "the Qt configure -graphicssystem switch" ?

[Thomas Luebking]

What's "the Qt configure -graphicssystem switch" ?
When I built Qt with raster mode on by default
;-)

Setting bespin through qtconfig with QT_GRAPHICSSYSTEM set to raster works, but when I
relaunch qtconfig (or any other Qt app), the blocks are back.

The environment affects the called application - it has NO impact for changing the style or similar, ie.
QT_GRAPHICSSYSTEM=raster qtconfig # qtconfig running on raster graphicssystem
[set style]
qtconfig # qtconfig does NOT magically run on the raster graphicssystem

Assuming bash:
export QT_GRAPHICSSYSTEM=raster # now set for all processes LAUNCHED FROM THIS SHELL

[R.J.V. Bertin]

Ahem, think I didn't know that? :P

I may be a tcsh user, but I've known the setenv command since, oh, 1989 or so ... O:^)

[R.J.V. Bertin]

To be more specific:

1> setenv QT_GRAPHICSSYSTEM raster
2> qtconfig # select bespin, works fine
3> qgit # some other Qt app, WTF, looks blocky!
4> qtconfig # yup, looks blocky, switch to some other style, back to bespin, ok, looks fine
5> # loop back to 3>

[Thomas Luebking]

I've a suspicion here - there is or used to be a bug in the raster graphicssystem (it "forgets" the alpha channel) which I work around.
However, the raster engine detection does not take place on non OSX (no xrender) systems - i could assume QT_NO_XRENDER is defined in your config.

For a quick test, blib/FX.cpp:222
- static bool useRaster = false;
+ static bool useRaster = true;

PS: sorry for treating you like an OSX user. You know, we believe you only use a virtual keyboard with the single buttoned mouse and such ... ;-P

[Thomas Luebking]

Revision 1730 has CMakeLists patches that should be sufficient - I omitted the "not apple" test around the X11/XRender_found tests (should be superfluous) and instead of altering the option defaults, hint that they're only relevant on X11/KWin.

I'll close this patch, please open a bug with your findings on the spurious config key issue.