Noises from the crypt… (Widgets on Graphics View update)

Published Tuesday October 30th, 2007
13 Comments on Noises from the crypt… (Widgets on Graphics View update)
Posted in Graphics View, KDE, Labs, Qt

Feature freeze for 4.4 is closing in. The offices in the dev department are awfully quiet. A bit… too quiet. The snippety-snapping sound of brilliant minds tapping in code, merging changes, polishing APIs, writing tests, reviewing patches. An incredible atmosphere, you would have to just be there to sense it. This is the period of Qt development when most of the building blocks are assembled, and awesome features and improvements emerge like glowing fresh steel from the furnace. This is the most busy, the most stressful, and by far the most fascinating phase.

Today in particular, I almost felt emotional. Together with Jan-Arve, Jo, Bjørn Erik, Benjamin, Girish, all brilliant developers, and everyone else who has participated in the Widgets on Graphics View project, I had the sensation that things were fitting so well together that you’d almost think we hadn’t invented these APIs, but rather uncovered ancient APIs from a past civilization. 😉 The pieces of the Widgets on Graphics View project are coming together. In very few weeks, they will be in your hands to test.

Early on, I was worried about many things. Prior to 4.2, I was almost convinced that adding embedded widget support to Graphics View would be an insane operation. Undoable. I think I was right. I’ll just list some of the problems we foresaw then, here:

  • QWidget cannot render itself onto an arbitrary painter like QGraphicsItem can… :-((
  • QPen is cosmetic by default. Will all styled widgets look strange when transformed?
  • Will the styles’ implicit pixmap caching slow everything down to the state of it being useless?
  • How does scroll optimization (QWidget::scroll) work for a transformed widget?
  • Qt already has widgets, do we have to clone all the APIs into separate Graphics Widgets with a duplicated implementation?
  • How can graphics items be part of the tab focus chain when they aren’t based on QWidget? (QWidget::setTabOrder…)
  • Do we need support for window flags? How about window activation? When is a Graphics Window activated?
  • Is there a concept of top-level window decorations in Graphics View, similar to QMdiSubArea?
  • How can we fool a QWidget into embedding itself into QGraphicsScene without it interfering with other widgets as if it wasn’t embedded? (Think about QuitOnLastWindowClosed, and so on…)

Sigh. Looking back, I don’t quite understand how we’ve made it. After numerous discussions with the guys directly involved in the project, and Lars, Brad (thanks for those long discussions in the car!), Paul, Jasmin, and many many other trolls, we’ve found solutions to almost every single problem that we foresaw. And we even uncovered more problems. And solved those too. And what we got, what we have, and what we’re honing, stabilizing, testing and reviewing these days, makes me emotional.

#include "mainwindow.h"
#include <QtGui>

int main(int argc, char **argv)
{
    QApplication app(argc, argv);

    QGraphicsScene scene;
    scene.addWidget(new MainWindow); // embed the whole thing

    QGraphicsView view(&scene);
    view.show();

    return app.exec();
}

I can’t wait to merge our stuff into Qt/main. When we do, it’ll be in the Qt/main snapshots. And then, you can all have a go. Give it a try. Embed your entire QMainWindow based app, with a QMdiArea central widget that embeds a QGraphicsView inside a QMdiSubWindow, and see it fly. When you do, you’ll get emotional too. I swear.

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

Posted in Graphics View, KDE, Labs, Qt

13 comments

pherthyl says:

Can’t wait to try it out. This could lead to something like CoreAnimation for Qt, to allow animated transitions with a minimum of code. Wow. This is going to blow some minds.

Aidan says:

Very cool, very intuitive.
I’m guessing I can then get the QGraphicsItem that is associated wit the QWidget?

john dalton says:

Thanks for adding this feature to 4.4! I think there’s some really amazing and useful things we’ll be able to do with this in our apps.

motif says:

What is the memory penalty for the mainwindow example you provided. And does the penalty occur just once, that is if you make your main window larger by adding more widgets does the GraphicsView overhead continue to grow as well

Finally an easy way to do special effects with Qt. Thanks for this contribution

Andreas says:

Hi, motif. There’s no memory penalty. Your main window will no longer allocate window resources, but QGraphicsView will instead. Beyond that, there’s no difference in memory use. Performance will go down, especially for transformed cases, although this is something we’re working on improving.

Peppe says:

Does this mean that I can add a QGraphicsView as an item in a QGraphicsScene that is displayed by another QGraphicsView which is into another QGraphicsScene that is displayed… 🙂

Andreas says:

Yes, Peppe, I’m afraid it does. 😉

qtuser says:

Does this mean that IF we want to put an embedded Qt widget in any graphicsview, even once, we must start our app in the way you describe in main.cpp?

(mainwindow goes into GV.)

ok. thanks!

Hmm… Maybe I can launch a helper app instead that does this and leave my current mainwindow app alone when I really need to do that.

Robert Knight says:

Hi Andreas,

Excellent. I’m really looking forward to this. One question that has been nagging me for a while though is how you handle the difference in the way coordinates are represented between the QWidget API, which uses integers, and the QGraphicsView API which uses qreals.

Andreas says:

Robert, we’ll provide a QGraphicsWidget class that use you can use to write your own qreal-based widgets. If you already have widgets that you’d like to port, that should be real easy. We’ll also provide a QGraphicsProxyWidget class that embeds any existing integer-widgets into Graphics View’s qreal-space. QMouseEvent (including its friends) is extended with QMouseEvent::posF() to prevent truncation of precision. Embedded widgets can be positioned in qreal-space but their geometry will snap-to-grid. Effectively this means the only drawback from the proxy is that the widget’s size will always be rounded to the closest integer – no way around that. But hey – you can still /transform/ the proxy widget item… fitInView(), rotate, and so on.

Peter says:

Great to hear you’ve not drop this feature! There were no posts for several months.

Then I could rewrite my d&d widget, and Trolltech the Designer. 😉

Looking forward to test it.

Jason says:

Excellent! We’ve been waiting for this since it was first rumored.

If you’re stabilizing this is there a list of what has made the 4.4 cut and what is being deferred until 4.5?

Gregory says:

any news ? is this already in the snapshots ?

Commenting closed.

Get started today with Qt Download now