Some time ago I wrote about our ideas for a new Qt widget set for QGraphicsView.
Up till now we have all been busy working on finishing Qt 4.6, so not much has happened since then.
But, it is now time to quote Hubert J. Farnsworth: “Good news, everyone!”. The Next Generation Qt Widgets project is of the ground!

Open Is The New Black

With Qt 4.6 released, we can now dedicate our time to Next Generation Qt Widgets. But we are not the only ones that will be working on this project. In addition to Qt developers, we will also have developers from INdT. And you are hereby invited to join as well!

liftoff by popofatticus on flickr

Jump Into The Fray

First, you want to clone the repository. It is also recommended that you browse the Qt wiki to get familiar with coding conventions and the contribution model. You may also want to read up on the rules. You should now be ready to join the discussions on IRC or on our mailing-list.
We are looking forward to seeing you there! Happy hacking!

Do you know the main advantage of a Hummer? It can go pretty much everywhere, that’s why many armies are using it. If I talk about a Hummer it is because QGraphicsView can go pretty much everywhere too. Recently I was lucky enough to get a N900 (generously given by Jesper, don’t know for how long though) so I decided to test Qt on it. I mainly work on QGraphicsView here at Qt Development Frameworks so it was a way to test the speed of my toy (:p). Since I’ve also been a KDE user and developer for quite a bit, I thought I could try KDE on it and more precisely Plasma.

So I downloaded the Maemo 5 SDK and started building KDE and Qt with it.

First thing you have to know is that scratchbox is not easy to set-up because you always face problems and compiling inside scratchbox is really slow. The link step is a bit broken and you have to specify manually where are the libs you link with (apparently it’s expected to be like that). It seems odd… Anyways, after a couple of hours I had Qt 4.6 (Fremantle branch) up and running. I was quite happy to see that it performs well (if you are using the right things). Animated tiles are running smoothly and painting demos as well (using opengl es2 graphicssystem).

After this initial success I tried KDE. This was more painful than I originally thought. Broken packages (mysql-server), out-dated packages (shared-mime-info for instance) and the worst : CMake crashed during the configure step. I solved that by downloading the 2.8 RC version that I built myself. But after a couple of hours of fighting and debugging I got this:

Link to youtube video

As you can see Plasma is running fine on this device. Of course a lot of work is needed to make it “finger” enabled (the actual applet handles are not really appropriate) but it’s a good start and Plasma is flexible enough to allow that. I have created a separate “shell” called plasma-mobile (Plasma already has the desktop and netbook shell) and I pushed that on the KDE playground. It also needs a lot of work to integrate well with the device (battery, network, profiles and so on) but the goal is to invite people to contribute to Plasma in order to offer a real alternative to the hildon-desktop. Plasma already has many many features/applets that we can just use on the N900. This also comes with a global effort to bring KDE technologies to the device as Kevin said in his blog. You can also participate in discussions on the KDE mailing-list for Maemo.

So yes Plasma is also a hummer, it runs everywhere but it’s the luxury version.

Some people have been asking how to embed Qt painted content (and especially Qt widgets) in a 3d scene. As I’ve been wanting to do this ever since we added QTransform supporting fully projective transformations, I sat down and wrote a small example demonstrating these capabilities. With no further delay, I present WolfenQt:

Here’s a screenshot as well for the Youtube-challenged:

A Wolfenstein like maze theme was chosen because of ease of implementation, you could of course embed a widget onto any 3d surface. The trick is to create a 3d transform mapping from a 2d plane (where the widget or other Qt drawn graphics resides) onto any quad in 3d space, and then do a perspective projection, before converting the 3d transform to a QTransform. Now, by making all the widgets and wall segments graphics items, you only need to use QGraphicsItem::setTransform() with the custom created transform and QGraphicsView will handle all event translation for you. The way the camera movement works is by recomputing and resetting every item’s transform on each frame. To avoid having to continuously redraw all the widgets if they’re not being updated, QGraphicsItem::setCacheMode(QGraphicsItem::ItemCoordinateCache) is the way to go.

I’ve embedded Qt’s media player demo to show the ability to embed videos in a QGraphicsView as tbastian blogged about just recently: Videos get pimped

I’ve also embedded the 3d .obj model viewer I blogged about earlier (Accelerate your widgets with OpenGL) to show how to mix in OpenGL content by setting up the correct projection and modelview matrices. Note that except from this 3d model everything else is drawn using QPainter with QTransform, both the walls, sprites, and widgets.

Now, this example might not be the most useful thing in the world, but it’s meant as a demonstration of how you can stretch the Qt API in new directions.

Want to play with the source? It’s available through our gitweb at http://labs.trolltech.com/gitweb?p=WolfenQt;a=summary

Note that the performance against Qt 4.5 is better than against Qt 4.4, so if you try it out you might want to use the 4.5 snapshots at the moment. For the very best performance run with the “-graphicssystem raster” option (So long and thanks for the blit!). Also, there seems to be some bugs regarding certain widgets not being shown on Windows/Mac. Left-clicking links in embedded QWebViews is also broken at the moment.

When I started working on our multimedia framework (aka Phonon) our goal was pretty simple and clear : we needed sound and video support in Qt. We had 3 systems to support and thus 3 completely different underlying API to implement our backends. It was tough and we worked hard on it. But then we got some cool demos and we saw that basic multimedia integration in a cross-platform way is actually possible. We struggled a lot but we got there. The mediaplayer demo is a nice little app that’s fully cross-platform and easy to understand.

Having a look at the bigger picture we realized that another great feature of Qt 4.4 is the ability to get widgets on the canvas (aka QGraphicsView). All our features need to work correctly together. That’s the basic principle of a framework. Displaying video is usually hardware-accelerated and all multimedia API/system use their own way to the graphics card. That means no composition with other widgets, no ability to paint over it and of course no perspective transformation.
My first thought at the time was that we would never be able to achieve the goal of full integration of our own features (ie. having videos on the canvas) and that felt bad.

We still tried and our target was Qt4.5. The biggest challenge was to write our own video renderer. Until Qt 4.4 we always used the native video renderers (you know, the ones without composition at all and no transform).
The 1st thing you have to do is manage the rendering of video frames and use the Qt paint engine. This way you get all the power of Qt.
So after a few weeks of development, tweaking and bug fixing I had something working.

So TADA! (If you were at dev days you’ve already seen that)

Now you can simply do something like that with your VideoWidget:
QGraphicsScene scene;
QGraphicsView view(&scene);
scene.addWidget(videoWidget);

I’m a bit lazy so I didn’t put the code that creates the Phonon objects. You can find out in the documentation and examples how to do that.
And now you can apply transformations to your video. Add things on top with alpha-blending… Possibilities unilimited.
And now you’re probably thinking that there’s a catch… and you’re right. If you look at your CPU usage it will be high. Because now everything is done in software including resizing/transforming/compositing/drawing. So we optimized, rewrote some components provided by the system (”OMG, how can the colorspace-conversion in MS DirectShow be so slow?!”).

Still, there is a way of greatly improve performance. Simply add that line to your code:

view.setViewport(new QGLWidget);

This magical line enables OpenGL through the whole canvas including your video. So scaling/transformation/composition is done by your graphics card. Plus on Windows I also use fragment shader to do the conversion from YUV to RGB (colorspace conversion) on the GPU of your graphics.

To make it even clearer I just made up an additional demo. I simply took the “embedded dialogs” demo from the graphicsview guys and slightly changed it. You can run this videowall demo. You have to pass at least one parameter which is either a video file or a directory (that contains video files) path.
So for example you do: videowall c:\videos
An additional parameter is the dimension of the wall. By default it is 1, meaning 1 video. If you pass for example 3, it will build a video wall with 3×3 videos. I ran it successfully with 9 videos (3×3 wall) with WMV HD content that I got from here. If you want to watch those videos you need to make sure you have the necessary codecs (Windows has them by default).

You can get the little demo here Videowall demo

And if you run it with something like videowall c:\videos 3, you can get the following result:

Now that you have speed and functionality, you can do whatever you want with your videos including using the new animation API!

To breathe some new life into the graphics dojo, here’s an example of how to put widgets on top of an OpenGL scene using QGraphicsView. By leveraging the synergy (tounge in cheek) of the OpenGL module and graphics view’s in 4.4 new widget capabilities, the long lacking feature of putting widgets in OpenGL becomes possible. All that’s needed is to set a QGLWidget as viewport on the graphics view, override QGraphicsScene::drawBackground() to do the OpenGL rendering, and add widgets and other graphics items to the graphics scene as usual. The result can be seen in the screenshot below, which shows a simple obj-model viewer application written in just a couple of hundred lines of code:

The source code is available by “svn checkout svn://labs.trolltech.com/svn/graphics/dojo/modelviewer”. Have fun!

Update (8 Feb 2010): Latest version of source code with some new patches is available at http://qt.gitorious.org/qt-labs/modelviewer

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.

Items or widgets? QGraphicsItem or QWidget? Which should I choose? Can you do everything with both? Mostly. You can write a games board widget, or a games board scene. An audio spectrum widget, or an audio spectrum item. Is QWidget faster? It can be, especially for simple widgets, and if you do everything right and have the time to spend. Will Graphics View save me time?

Maybe the task you’re trying to solve is a perfect match for Graphics View, and as you go along implementing it, you implement zooming and scrolling and right there I’d like to double-click to open a line edit - pushbutton box but… how? Maybe you search the QGraphicsItem docs and can’t find anything, so you create a QPushButton, and uh.. Where do I put it? Who is its parent? What do I do when the user scrolls the view? (Install event filters?)

void MyItem::mouseDoubleClickEvent(QGraphicsSceneMouseEvent *event)
{
    QPushButton *button = new QPushButton("Hello!", event->widget());
    button->move("#¤!¤ &am!#¤!"#¤%&/(/p;!¤#QRE // censored
}

Embedding a widget inside a QGraphicsScene… does stir your interest? Have you ever invested time and energy on creating the world’s finest widget, and then wanted to use it with Graphics View? Or maybe your scene could use a combobox /right there/, but then you go… oh, I don’t have any QGraphicsComboBoxItem. So what do you do?

• Put the widget on one of the QGraphicsViews’ viewports… somewhere.
  • It’s /the/ widget, no emulation, no nothing.
  • Supports any widget, even custom widgets.
  • But: It’s hard to keep track of the item’s movement.
  • But: The item cannot be transformed. OTOH, it always looks right.
  • But: The item is always on top of the non-widget items (i.e., stacking order does not apply anymore).
  • But: With several views, the widget will have to pick one somehow.
• Keep the actual widget outside the desktop, create an “emulator” item that draws by redirecting the painter, and sending paint events.
  • Supports any widget, even custom widgets.
  • You can have the same widget in many views.
  • You can transform the widget (but it won’t necessarily look good).
  • But: You have to emulate all events, and the widget can only support the subset of what QGraphicsItem supports.
  • But: It’s a horrible horrible hack, and I don’t even know if it works at all ;-).
• Write your own widget item, using QStyle to make it look like a real widget.
  • You have full control over the item, and can make it do what you want.
  • But: You have to write one item for each widget you want.
  • But: QStyle isn’t exactly resolution-independent. Rotating something that uses cosmetic pens, for example?….
  • But: As fun as it may sound, you still have to implement all the logics inside the item yourself.

With either approach, what you want is to end up with something like this, graphics items and widgets dancing together as if nothing had happened:

I myself and several other Trolls’ve spent some time researching this topic. It’s not trivial; most solutions to embedding widgets into a scene end up with several serious drawbacks. That’s also why Qt doesn’t have any off-the-shelf solution to this.

• Widgets cannot be scaled or rotated, but graphics items can.
• Widgets can only appear once on the desktop, but several views can observe one graphicsitem.
• Widgets express their geometries in pixels, graphics items use logical units. (…int vs. double)
• Widgets support tons of features that graphics items don’t understand. Just look at QWidget’s property docs.
• Widgets understand layouts, graphics items don’t.
• 4000000 widgets don’t work that well, but 4000000 items works perfectly.

So, fundamentally, the two are very different. But place some push button items on a scene, and pull up a view, and compare that to QPushButtons inside a QScrollArea, the two look the same, and feel the same. But they aren’t the same. And that especially comes into play when you try to combine them.

I think the most reasonable thing to do is to either use the widget directly, or write your own custom control. To demonstrate the first approach, I’ve added a Graphics View experimental items section in Labs. You can take a look, download the example and see how it works. This approach doesn’t support transformations, but… when was the last time you typed text comfortably into a line edit at a 22 degree angle?…

http://labs.trolltech.com/page/Projects/Graphics_View/Graphics_Items

Btw, later on we’ll be adding more experimental items to this page. If you have suggestions, please let us know.

I don’t have much to say this time, just wanted to share a screenshot after I changed the 40000 Chips demo a bit. I replaced the single horizontal rotation-slider with three ones, each controlling one axis or rotation for the view. QTransform is really easy to use, and with some twiddling (thumb up, pointing finger straight and your index finger pointing to the left), you can get some pretty amazing effects.

QGraphicsView view(&scene);

view.setTransform(transform);
view.show();

Setting one on a QGraphicsView works well, but there are still some rough edges that’ll get fixed pretty soon. Anyway, this is what it looks like (interaction works just as well).

We’re in the process of closing up the features for 4.3, and I’ve had a little run-down of what’s changed in Graphics View.

In general, you will notice that the graphics run faster, (especially for complex polygons,) collisions are absolutely precise, the rubberband looks 100x better… I think most of our Graphics View followers will be very pleased with the upcoming Qt 4.3.

When the first beta is released, it’s nice if you as a Graphics View developer try out your Qt 4.2 app with 4.3, so that we can nail out any possible regressions (both behavior and speed) before the final version is out. So please, let us know :-).

Here are some of the new features:

• QGraphicsView has some new properties.
  • viewportUpdateMode: Now you can fine-tune how the viewport reacts the changes in the scene.
  • rubberBandSelectionMode: For those who want to select items that are inside but don’t intersect with the rubberband…
  • optimizationFlags: If you want faster graphics, away goes the safety net…
• All flicker in rubberband mode is gone.
• You can also transform the view with a QTransform; this works best for small scenes, though. But the effect of seeing your scene with perspective transformations is pretty cool.
• QGraphicsItem has some new flags.
  • ItemClipsToShape: All item rendering is clipped to its own shape
  • ItemClipsChildrenToShape: Like widgets, the parent item clips all its descendents.
  • ItemIgnoresTransformations: The lovable item that just won’t transform… well.

There’s been some under-the-hood changes too. Where before, if you moved an item, it would always get continuously reindexed (for each mouse move event), now it goes into an intermediate state that keeps the item outside the index until you leave it for a while. When moving a lot of items together, this makes a huge difference. It also means you don’t have to use NoIndex for scenes that combine animated and static items! It’ll still be pretty fast.

Check out the chip demo, or run the Colliding Mice example in one window, and top/Task Manager in the other; it’s faster in Qt 4.3 snapshots!

[no carrier] - /me waits for the first comment going “Hey, it’s not fast at all!”

Last summer, while we were finishing up 4.2, there was a great deal of activity on the mailing lists we set up for the 4.2 technical preview (http://lists.trolltech.com/). Some people kept on asking for support for “untransformable” items, that is, special QGraphicsItem items that don’t follow the parent’s or view’s transformations. Like the text labels in Google Earth, they stay horizontal when you rotate, and don’t change their size when you zoom.

Because of the risk of destabilizing the base behavior, we decided to postpone such a feature, and it was moved into research.

Good news, it looks like we will be adding this feature to 4.3. It’s still in research, but working quite well. There are some minor details to iron out, but mostly under the hood and they will not affect the API or behavior in any way.

Click to see a short animation.

To trigger this special behavior, you set a flag: ItemIgnoresViewTransformations (, or something like that). Then you can add the item as a regular child of another item. Its position will then show where the item is “anchored” to its parent. And the item is rendered without any rotation or scaling imposed by the view. For example:

QLinearGradient gradient(-100, -100, 0, 100);
gradient.setColorAt(0, QColor(128, 255, 192));
gradient.setColorAt(1, QColor(63, 255, 63));

// Create a scene, add the main ellipse.
QGraphicsScene scene;
QGraphicsEllipseItem *ellipse
= scene.addEllipse(QRectF(-100, -100, 200, 200),
QPen(Qt::black, 2), gradient);

// Add two child lines that cross over the ellipse.
QGraphicsLineItem *line1 = new QGraphicsLineItem(-100, 0, 100, 0, ellipse);
line1->setPen(QPen(Qt::black, 3));
QGraphicsLineItem *line2 = new QGraphicsLineItem(0, -100, 0, 100, ellipse);
line2->setPen(QPen(Qt::black, 3));

// Add five _untransformable_ text items around the ellipse.
for (int i = 0; i setParentItem(ellipse);
text->setFlag(QGraphicsItem::ItemIgnoresViewTransformations);
text->setPos(100 * cos((6.28 * i) / 5.0), 100 * sin((6.28 * i) / 5.0));

QFont font;
font.setPixelSize(20);
text->setFont(font);
}

The items still follow regular items’ rendering constraints (e.g., the stacking order is the same as with normal items). You can also rotate or scale the item itself; that still works. It just doesn’t inherit any transformations.

PS: The Hell Wyrm has been defeated! It took me a good 1.5 hrs of continuous struggle to nail this mark. Can you believe that it’s got 6 million HP??