I can haz teh future, kthx?

Published Friday October 9th, 2009
7 Comments on I can haz teh future, kthx?
Posted in Graphics View, Itemviews, Kinetic, Labs, Qt

So, are we in the future yet? It is 2009. Where are all the flying cars and personal jet-packs ? Surely we would all be wearing metallic outfits (complete with Employee Visualization Appendage) by now.

The Future Is A Canvas

Back in 2006 a little bit of the future arrived when QGraphicsView was introduced, we were aiming to replace our old QCanvas API with something more flexible and powerful.
It turns out that it is great for creating dynamic, smooth and animated GUIs. Over time it has become the backbone for next-generation user-interface projects like KDE’s Plasma and Qt Declarative UI.

Yet, for all its dynamic, smooth goodness, there are some missing pieces in the puzzle. People are creating full user interfaces in graphicsview, but Qt offers only the most basic widget types to help them out. In many cases it is enough to offer basic primitive types. But if you want to integrate with the platform you are running on or want to use more complex widgets, it becomes difficult.

The Shiny New Stuff

This is why we have started a research project aimed at providing a basic widget-set based on QGraphicsItem. It is a natural extension of the Next Generation Itemviews project. We will take the opportunity to look at how to improve the widget API, internal structure and how we do widget styling and theming.

HotWheels by Leap Kye on flickr
HotWheels by Leap Kye on flickr

One of the lessons we have learned is that graphics hardware is generally happier when moving pixmaps around, than when drawing lines and shapes again and again. This has implications for the styling API, since our current QStyle is based around drawing complex controls imperatively. It would be better to build our widgets as a graph of (cached) primitive elements that can be transformed and updated individually if necessary.
Similarly it also makes sense to make the input regions in the widget into separate elements in that scene graph.

But, for all our fascination with the new and shiny, we should not forget that our existing widgets contain years of accumulated experience in the form of code that handles all sorts of weird and wonderful corner cases. We don’t want to go though the pain of re-discovering all these cases. It makes sense to re-use existing logic and behavioral code by moving this code into classes that can be used by both the old and the new widgets, when possible. This will also allow us to directly test and verify the internal widget logics independent of the widget front-end.

Still Kinkin’ It Old School ?

We are not forgetting our QWidget based widgets. They will get some initial benefit of better tested back-ends and hopefully some code cleanup. I also have some ideas that will drag QWidget kicking and screaming into the future, but I’ll leave those for another blog-post. Always leave the audience wanting more. 😉

Talk To Us

Even though we are currently working full time on getting Qt 4.6 out the door, the widgets-ng repository is already public and we are already hanging out on #qt-widgets-ng on irc.freenode.net .
I will be attending the Qt Developer Days in München next week, and there will be several developers from the Qt Widgets Team attending the San Francisco event too. Feel free to discuss anything widget related (or any random topic, really) with us. See you there!

Do you like this? Share it
Share on LinkedInGoogle+Share on FacebookTweet about this on Twitter

Posted in Graphics View, Itemviews, Kinetic, Labs, Qt


lulzfish says:

Sounds pretty cool, I suppose this will make it easier to add nice widgets to games and other OpenGL applications? Especially since Qt is considering a gaming API.

stephenju says:

What does this mean to coders who are using plain window-based UI? I don’t do full screen UI or web. Does this mean a shift from making apps running on different platforms look native, to the same UI look across the board?

Adam Higerd says:

@stephenju: Given that being native on all supported platforms is one of Qt4’s biggest selling points, don’t expect that to go away. Do expect to see performance improvements!

Paul says:

Great to see the roadmap supporting more creative UIs suited to embedded products.

Now all we need is QTScript-LLVM cooperation for JIT-compilation of scripting ( new declarative UI features) at near native speeds and embedded products should be a lot better to develop quickly.

Henrik Hartz says:

@stephenju rich client apps with native controls and platform-specific L&F (i.e. QWidget-based) will continue to play an important role in developers life and we’re not planning on deprecating this anytime soon. See mbm’s “Still Kinkin’ It Old School ?” paragraph. See you in Munich mbm!

Satya says:

So sooner or later Qt DeclarativeUI api is going to replace Qt Widgets which are here for a long time.As we can see QtDeclarative UI’s are agile,and occupy very less size making them more friendly towards resource constrained devices.

Ariya Hidayat says:

@Paul: Qt 4.6’s QtScript module, which is using WebKit’s JavaScriptCore as the back-end, already supports JIT compile.

Commenting closed.

Get started today with Qt Download now