[Interest] My experience porting to Qt5 (on OS X)

[Till Oliver Knoll]

2012/9/3  <morten.sorvig at nokia.com>:
>
> On Sep 2, 2012, at 1:38 PM, ext Till Oliver Knoll <till.oliver.knoll at gmail.com> wrote:
>
>> Hi,
>>
>
> Hi! Thanks for testing. Commenting on some of the issues below:
>
>>
>> GOOD:
>>
>> ... Not sure whether I really want
>> this (should be a window configuration flag maybe - or maybe that's
>> already present as an option?)
>
> We should probably add a flag, and find a way to fit the tree options (on, off, auto) into Qt::WindowFlags..

That would be very useful to have the option to enable/disable it with
such a flag. Whether it should be enabled by default I leave it up to
the usability experts to discuss (most Apple applications such as
Calendar, iPhoto... do have this option, must some others don't, such
as the Finder, IIRC. Not sure what the exact philosophy is behind
"When should an application support fullscreen").

>
>>
>> BAD:
>
>> - Lots of rendering artifacts (mostly seems like a "refresh" problem:
>> old pixel "blocks" remain on the screen until a repaint is enforced,
>> e.g. by rescaling the window - can also be observed with the Qt 5
>> Designer etc.)
>
> This is unexpected, we've been running for example Qt Creator on Qt 5 artifact-free. As you note elsewhere it could be a 10.6 issue.

Actually my first impression is the other way round: I observed those
artifacts on OS X 10.8.1 (Mountain Lion). Somehow I have the feeling
that it is related to some "redraw events" going missing. For instance
I remember one example application which dumps the OpenGL driver info
(I think it is somewhere in the Qt3D examples, can't remember it's
name). When I started it I only saw to rectangles (widget frames?),
but the content remained "white" (or at least empty). Only when I
resized the window was the text/content rendered.

Also Qt Designer showed some render artifacts, such that when you move
a dialog (the one being designed) or resize the toolbars that
sometimes "the old pixel (blocks) were left behind" (like a
redraw/clear missing).


On OS X 10.6 (Snow Leopard) however (I only tested VERY quickly!) I
did not observe such artifacts yet, also my own application seemed to
be "artifact-free".

Off course we're also talking about different graphics cards here:
10.8 is installed on some 13" MacBook Pro, model mid 2010, whereas
10.6 is installed on some older 27" iMac 2009.


I will try to narrow down these issues and come up with reproducible
examples before I report anything. And again, my "testing effort" so
far was really just very short so far!

>> - setUnifiedTitleAndToolBarOnMac(true) doesn't seem to have an effect
>> anymore:
>>
>>   THIS IS AN ABSOLUTE SHOW-STOPPER ON MAC!
>
> I don't want to bring setUnifiedTitleAndToolBarOnMac forward to Qt 5. There are two reasons for this:
>
> - It's a horrible hack. In Qt 4 we move the toolbar out of it's containing main window, embed it in an external NSView, and then #ifdef all the layout code to account for the missing toolbar.

Hehe, yes, I remember some issues, for instance when trying to
re-position a main window at program startup to the "last known
position and size" (QSettings) there used to be an "offset" each time
you restarted the application. That was fixed in 4.8.1 (or 4.8.2
only).

Myself I encountered also strange visibility hacks in my own
application with the "unified" toolbar, when hacking my own pre-5.0
"fullscreen" support (using the native Cocoa APIs, which was actually
quite easy): sometimes the toolbar disappeared when switching back to
normal view, it did not show again when toggling its visibility etc.

I am very glad I can remove all my hacks (such as re-setting the
toolbar "unified" when the window became visible etc.) now that "Lion
fullscreen" support works flawlessly!

(Also refer to https://bugreports.qt-project.org/browse/QTBUG-21607
and https://bugreports.qt-project.org/browse/QTBUG-22043 - the later
can be considered "Solved" in Qt 5 ;))

> - It emulates a native toolbar. This gives you something that looks similar, but behaves slightly different.
>
> Instead, I see two possible replacements:
>
> - Wrap NSToolBar in a QAction-based API. This gives you access to the real NSToolBar, with perfect native look-and-feel (Including the customisation menu). The downside is that you have to play by the NSToolBar rules. Research work on this option is underway, see http://qt.gitorious.org/qtplayground/qtmacextras.

That would be great! I am not sure what the implication of "playing
according to the NSToolBar rules" would be, but as long as those would
be "the same restrictions a Mac application has to follow anyway" then
that would be no problem.

(For instance re-positioning the toolbar was already not possible with
the previous "unified" toolbar was - which is absolutely fine with
me).

> - Expand QWindow to cover the toolbar/titlebar area. Qt would then be free to draw the toolbar is it likes. Chrome does something like this to implement tabs-on-top, so it's not completely unprecedented.

Would be okay for me as well: "As long as it walks like a duck and
swims like a duck and quacks like a duck, I call that bird a duck!"


It's good to know that this issue "has not been overlooked" ;) - thanks!

;)

Cheers,
  Oliver