[Qt-interest] how to start again (for real, this time)

[Till Oliver Knoll]

Am 27.02.11 01:51, schrieb Andrea Franceschini:
> 2011/2/26 Jason H <scorp1us at yahoo.com>:
> 
>> Welcome back.
> 
> Thanks, glad to be :)
> 
>> QML is the "new" UI paradigm. (In cluding QGraphicsView which replaces QCanvas)
> 
> I see. I used to work with Designer which produced those ui files that
> were fed to the moc and everything. Is this QML supposed to replace
> that process or is that process still useful and recommended for some
> applications?

*.ui files are actually fed to the uic ("user interface compiler", which
generates the C++ code for the UI) and then partly also to the moc
("meta object compiler", which generates the signal/slot connections and
meta info for the previously generated C++ ui class), but that is just a
technical detail ;)

The point here is that for *desktop* applications the Qt Designer and
*.ui way are still the way to go!

Yes, they look "less sexy", but that is exactly the idea for desktop
applications: they are supposed to "blend in" into the native "look and
feel", use native widgets wherever possible etc.

But if you are after "pixel-perfect" and "fixed size" applications - the
setup screen of a game, for instance, which is run in full-screen anyway
- then the UML is a viable alternative on the desktops as well! Or if
you have any other "it has to look exactly like this on any platform"-needs.

Basically UML was introduced for mobile and embedded devices ("fixed
size/full-screen apps") and the QWidget approach is just "too
heavy-weight" (resource-wise) for those devices (and for obvious other
reasons not suitable, such that it does not make sense to have resizable
"dialogs" on such devices etc.)

But UML is not supposed to replace the UI approach! It merely
complements it and the idea is also that it is also more "accessible" to
designers used to script and declarative languages.


But personally I think the Qt Designer + UI approach is still one of
*the best* solutions out there, the generated code is clearly separated
from your own and the layout is as simple as dragging the widgets to the
proper place and choose one of the intuitive layouts (when I think of
these "card layouts" or "north-west-south-east" layouts of Java...
*shudder*! They were never really clear to me without studying
intensively their JavaDoc... and the next day I had already forgotten
again how to use them).

Don't know where Visual Studio with their .Net widgets are currently,
but they are not really cross-platform, so not really comparable. But
MFC with their "fixed layout" thinking... gosh!

> I also remember asking whether it was possible to draw fully working
> widgets (with events and interaction) inside an OpenGL viewport while
> also transforming them in the 3D space (like translation, rotation...)
> and the answer was something like "yes, this is going to happen soon".

Have a look at the current Qt demos. Unfortunatelly it seems that the
"widget proxy" approach introduced somewhere in Qt 4.4 (?) is already
deprecated (not officialy yet I guess, but there was a discussion here a
few weeks ago indicating that this approach would not get any more
love). Apparently its performance scales badly, but I guess the real
reason was/is that development focus shifted to QML. Some users said the
performance is just fine for them!

But anyway, the idea is that you have a QGraphicsView with an underlying
QGLWidget as paint widget (= rendering done in OpenGL) and you can add
QWidgets via a

  http://doc.qt.nokia.com/latest/qgraphicsproxywidget.html

once you have done so you can scale, rotate and shear those widgets as
you wish. Their pixmap is then rendered using OpenGL.

Besides using a QPainter you can also mix "raw OpenGL" commands/painting
with QPainter painting onto a QGraphicsView. There is an example
somewhere in the Qt distribution, but it is not so easy, you have to be
careful to clearly separate the OpenGL matrix stack with the QPainter
transformation matrix stack.

Therefore

  http://doc.qt.nokia.com/latest/qpainter.html#beginNativePainting

has been introduced with which you can tell "Now I want to render with
raw OpenGL commands", restoring the QPainter state with the corresponding

  http://doc.qt.nokia.com/latest/qpainter.html#endNativePainting

There are a few more caveats, refer to the Qt example. I think there is
also an example in the "Qt Demo" suite, see under OpenGL (I think),
where they mix QDialog widgets with OpenGL rendering.


Cheers,
  Oliver