[Qt-interest] Clarification on "out of scope" closed bug

[Oliver.Knoll at comit.ch]

On 2011-01-19 Thiago Thiago Macieira wrote:

>> ... I hope there is a relatively easy 
>> migration path so we don't end up down a dead end.
> 
> The migration path is to redo your widgets entirely in Graphics View.

As a matter of fact I am at the very edge of deciding myself how to render "QDialog" based widgets ("Property dialog" which is moved along with the item it is attached to, some decent transparency background, a custom "close" button, no title bar etc....) 

What does "redo your widgets" mean in this QGraphicsView context? Derive from http://doc.qt.nokia.com/4.7/qgraphicswidget.html and re-implement the custom painting and all the mouse interaction ("push button clicked")? Or I would implement my own QGraphicsPushButton, possibly derived from QGraphicsPixmap item and add this to the QGraphicsLayout of the given QGraphicsWidget? 

So basically I would (almost) end up with what QGraphicsProxyWidget would do, but instead of "wrapping" existing QWidgets I would re-implement every widget (QPushButton -> QGraphicsPushButton, QLineEdit -> QGraphicsLineEdit, ...) I would need in my QGraphicsDialog, with all the needed "custom" painting and mouse/keyboard handling, right?

Is that (roughly) what you mean with "redo your widgets" (Besides using QML)?


Or why is QGraphicsProxyWidget not the recommended way again (besides performance)? How performace-consuming is it really? My QGraphicsScene is not very complex, and not even OpenGL based (no real-time animations in the background). I have a few items (QGraphicsPixmap) and need some "propery dialogs". If moving the items while such a "dialog" is being shown (with a QGraphicsProxyWidget) is slightly less performant, I can live with that.

However, if there are serious drawing bugs like the one mentioned, and these bugs are unlikely to be fixed, or worse, the whole concept of QGraphicsProxyWidget is likely to be "abandoned", well then, no point in start using it :(

Well, then, QML: I am very reluctant with using that technology on a desktop, mainly because of my dislike of specifying a UI in a textual/declarative way (call be conservative ;) rather than a "designer way", where I have direct access to the actual widgets later on with a  programmatic "Qt API" ("enable/disable" widgets "in C++, rather than some "JavaScript/XML").

But that personal "dislike" could probably easily solved in that I would start using Qt Designer (which apparently has "UML support", but to be honest I have never tried it so far).

But my main reason why I am a bit skeptical is that "UML does not look native"! I just had a quick look at the more "widget" oriented QML examples, examples\declarative\ui-components\progressbar or examples\declarative\ui-components\searchbox etc.: on a Windows XP those "line edits" and "scroll bars" don't look like "Windows UI elements"! Off course not, they are custom painted. I agree that the examples look impressive, and performance is very good. But they don't look native.

That is fine for mobile phones where there are no "standard widgets" yet maybe... yes, I was talking about a dialog with "decent transparent background and custom close button". But I still want to have Mac push buttons on Mac and Windows push buttons on Windows... by simply re-using QPushButton which does exactly this for me!

So until I can use QML to design "native looking main windows with menus and everything I know so far from Qt Designer/Qt API" QML is for me "mobile phones only", or put in other words: uninteresting so far (since I don't do mobile platform development) 

So currently QML is absolutely no replacement for me for the traditional QWidget (or QGraphicsProxyWidget, to close the circle) based approach, where I want "native" widgets and behaviour! And which is fine, after all QML's primary focus are mobile phones with a fixed screen size.

Bottom line: the traditional "desktop" development, a traditional key strength of Qt, should not be abandoned and people should not be expected to abandon their "traditional way of developing" in favour of some mobile phone technology either, which "does not look native". Because the later point - looking native - is another key strength of Qt, and I don't see how QML would fulfill that in the near future (I might be proven wrong, though ;)

However, Nokia's quick reaction to the "App Mac Store compatibility" demand (refer to http://bugreports.qt.nokia.com/browse/QTBUG-16590 - I still hope that that one will make it into the upcoming 4.7.2 ;) or the handling of Gesture support on Mac notebooks, just to name a few "desktop examples", still leaves me in good hope that Qt will continue its great support for desktops! And I am looking forward when I can develop for more than just one mobile platform (not counting the existing "Windows Mobile" support ;) with QML *hint* *hint* ;)

Just my 2 cents,
 
Cheers, 
  Oliver
--
Oliver Knoll
Dipl. Informatik-Ing. ETH
COMIT AG - ++41 79 520 95 22