The day has finally arrived. We are proud to announce that we have now integrated our development branch for the Widgets On The Canvas project into Qt/main, or what will become Qt 4.4. You have already seen a random selection of screenshots and feature rundowns in previous blogs, but now it’s all in your hands to try and enjoy. It should appear in tonight’s snapshots.
I’d like to thank Jan-Arve, Bjørn Erik, Jo, Benjamin, Jasmin, Girish, Lars, and everyone else who has helped us with rowing this boat ashore. It was a beast, but we seem to have managed to tame it. Now, we’d all like for you to play around with this API, and let us know what you think.
Graphics View now provides a brand new layout and widget API. It’s similar to the way QWidget works, and should be familiar for most of you right away. The purpose of this API is mainly so you can write layout-aware items, but it also means you now have a richer base class for your items. Because QGraphicsWidget inherits from QObject, it allows declaring signals and slots and manages event delivery just like any widget in Qt. Like QWidget it also provides a palette, a font, layout directions and a style.
Graphics View doesn’t provide its own widgets like QLineEdit and QComboBox – instead, you can embed existing widgets (indeed, any custom widget that you have written yourself) into the scene by calling QGraphicsScene::addWidget(). If you also pass the Qt::Window flag, your widgets will even get window decorations similar to QMdiSubWindow. You can move, resize, rotate and scale your widgets, or combine widgets and items to generate fancy overlay or transition effects.
There are still a few remaining issues to solve. For one, Graphics View automatically embeds popups of embedded widgets. So if you embed a combobox, its popup will also appear as an embedded popup inside the scene. And QMenuBar’s menus also also embedded. We aim to make this feature work 100% for 4.4, but currently it doesn’t work properly (in particular, modality and mouse grabs are missing). Also, there’s the well-known Mac OS X styling problem. We still haven’t found a perfect solution for this, so for now, if you use Mac style for Graphics View, embedded widgets will look a bit chunky when transformed. And finally, because this is all brand new API, we expect some bugs to appear in this pre-alpha phase, and hope to iron them out based on your feedback. But hey – Widgets on Graphics View! How about it??? 
PS: The members of the WOC project are all present and listening on qt4-preview-feedback@trolltech.com (also available through nntp.trolltech.com). Now is the time that you can help hone Widgets on Canvas to be just as great as we all want it to be. So enjoy! We’re eagerly awaiting your feedback.
Possibly related posts:
16 comments
Can’t wait to get my QWidgets on QGraphicsView at workplace and dazzle everyone.
Looks amazing!, you just got me to update from 4.3 to svn head just for this ;P
Looking forward to integrate the feature to kshower…
Great, have been waiting for this. I will get this snapshot asap.
Great work! If only plasma had waited for qt4.4 , there wouldn’t be duplication of some work
Anyways very cool feature, hats off to you all responsible for this feature
Expect a lot of traffic on your ftp tonight
!! (I will be polling every msec 
)
Could lead to some interesting possibilities. Is it possible to place a drop-shadow behind a widget in QGraphicsView? The obvious way to do this would be to make the drop-shadow a child of the widget. But the children of a widgets are always stacked above the widget in the z order.
wow – this is really amazing!!
Ok, so how did you solve the focus problem? Who gets the focus if one scene is displayed in more than one view? Could you explain what the problem was and what the final behaviour is? And maybe some hints on how did you actually solve it…
Andy Brice: There’s a separate API for rendering window decorations – you can render drop-shadows there too. Check out QGraphicsWidget::paintWindowFrame() and friends. We haven’t added classes for window decos, but you can do that yourself easily.
Wysota: The focus problem – when a view gains focus, it gives the scene focus. If another view gains focus, the first loses focus, stealing focus from the scene, and the other gives focus back to the scene. As for activation, if two views in the same window view the same scene, the scene is activated once. We went for the reference counting approach, ensuring that the scene is activated once and only once even though two active views are viewing it, and zero-or-one of the views has focus. When both views have been deactivated, the scene is deactivated. This also ensures that the scene stays active if two views in separate windows are viewing the same scene. The only drawback is that the inactive window will also render the scene as active. Enjoy!
> The only drawback is that the inactive window will also render the scene as active.
This indeed doesn’t seem very natural.
Great work! Keep it up you Trolls!
/me bows before the great trollish wisdom
Excellent!
The Plasma-Developers are happy now I guess
.
Awesome. Thanks
Finally the waiting is over
. Is it also going to be integrated into Qt Jambi?
Does this also work with embedded GLWidgets?
Is this new 4.4 compatible with Qtopia?
Comments on this entry are closed.