Graphics View with layouts and widgets?

Published Monday April 2nd, 2007
1 Comment on Graphics View with layouts and widgets?
Posted in Graphics View, Labs, Qt

On the way to work today, on the train, I thought about how I can make this Monday the best possible. There’s a lot of stuff going on, and the art of getting Monday morning right sounded very appealing. So here I am; I’ve put on the Katamari soundtrack, wearing big earphones, sipping coffee and blogging about Graphics View. It’s working quite well :-)..

Lately I’ve been spending some more time researching “widgets on the canvas” and resolution independent UIs in general. It’s quite an interesting topic; there’s a lot of information to gather before we decide on what approach is most suitable for Qt. As for widgets on the canvas, the hot topic is whether we can support putting actual QWidgets on a scene, or if we need to fork our dear widgets and breed a new transformable species… One of the two might stand out as an obvious solution to you, but I can’t guess which one now that I see so many pros and cons for both approaches.

As a proof of concept, I ported QLayout to Graphics View, just to see if there are any immediate problems. Here’s what I got:

Graphics View, Big Button QGraphicsItems in a layout

This picture shows QPushButtons in a QLayout, that is, several QPushButton clones inside a QGraphicsGridLayout. Running XP style. This experiment has brought up some important issues that need to be resolved:

  • We need a layout-capable item, probably a QGraphicsWidget-like item with a geometry.
    • QGraphicsItem::children() conflicts with QObject::children() (argh, why didn’t we fix this before 4.2)
    • QGraphicsItem already has three geometry functions, so this widget might end up with like… 5 geometries. Confused?
    • The item needs to pick its style / font / palette from… what view? 😉
  • Layouts with qreals are incredibly cool, and powerful. You can specify a margin of 1.5 :-D. But for platforms that emulate floating points, doubles and floats are really slow (10-200x slower than ints).
  • The buttons are drawn using QStyle, which is very pixel-oriented.
  • No styles take transformations into consideration. For example, the way we do pixmap cacheing today is completely useless, exhausts memory and slows everything down for transformed widgets.
  • Styles that use cosmetic pens (almost all styles do) look bad when transformed. In general, styles that try to use dots and lines look like frak when you zoom in ;-). I tried to do a little “search-and-replace” and the patch filled my home partition. No, just kidding… but the change is significant.

So far, my Monday morning is looking good. I’ve got some QSslSocket work to do, and some test fixing, and subconsciously I’m thinking about resolution independence 90% of my idle time. Which is fun ;-). There are so many possible solutions, and I foresee no problems in the showstopper category.

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

Posted in Graphics View, Labs, Qt

One comment

Jason says:

You have idle time??!?!
I don’t think the concerns you outline above are very concerning. I of course am extremely naive
.
* We need a layout-capable item, probably a QGraphicsWidget-like item with a geometry.
o QGraphicsItem::children() conflicts with QObject::children() (argh, why didn’t we fix this before 4.2) — fix it in 4.3?
o QGraphicsItem already has three geometry functions, so this widget might end up with like… 5 geometries. Confused? — What’s a geometry? and why are there different ones?
o The item needs to pick its style / font / palette from… what view? 😉 — The parent, naturally. 🙂
* Layouts with qreals are incredibly cool, and powerful. You can specify a margin of 1.5 :-D. But for platforms that emulate floating points, doubles and floats are really slow (10-200x slower than ints). — As a former embedded programmer, I appreciate this consideration, but we can’t let that hold Qt on larger markets back. Let the embedded people use only ints if they only have a IPU.
* The buttons are drawn using QStyle, which is very pixel-oriented. — Not from what I’ve seen (which is admittedly very little) Paths and such are vectors, pixels are easily converted to stroke widths.
* No styles take transformations into consideration. For example, the way we do pixmap cacheing today is completely useless, exhausts memory and slows everything down for transformed widgets. — Should it need to? Save the transforms for later in the composting process.
* Styles that use cosmetic pens (almost all styles do) look bad when transformed. In general, styles that try to use dots and lines look like frak when you zoom in ;-). I tried to do a little “search-and-replace” and the patch filled my home partition. No, just kidding… but the change is significant. — It may be that ideal implementation is a ways away, but we can let the programmers handle the nitty-gritty for now.

I think the idea of QGraphics and QWidget merging is compelling because the concept is nothing more than moving from Integers to Floats. For floats, there is almost always a vector technology for every integer technology. The only thign that comes to mind as not existing are raster effects, like glow effects (gradients that are calculated on a object after it has been rendered. But even then is possible to construct a tangential gradient stroke pen and trace the outline to achieve the effect.

The problem I have with all of this, is now I don’t know which container to choose – the scene or the widget?? It’d be nice to say it only matter if you have an FPU or not. Vector interfaces are the way to go!

Commenting closed.

Get started today with Qt Download now