[Qt-interest] QGraphicsItem ignore scene translation/transform?

Thomas Fjellstrom tfjellstrom at shaw.ca
Mon Jan 25 12:28:40 CET 2010


On Mon January 25 2010, you wrote:
> ext Thomas Fjellstrom wrote:
> > Ok, I think I've got a plan now that just might work.
> >
> > Manually draw the board with a single "Smarter" widget that handles its
> > own internal translation and transformation.
> >
> > To do that I'd need to either not add the board square items to the
> > board, and then draw each one manually when I think it might be dirty,
> > or do the same, but make the BoardSquare's a plain QObject (instead of
> > a QGraphicsWidget subclass ). Either way aught to work, and would
> > result in the same api for the BoardSquares (paint()). Going either
> > route is essentially the same, and would allow me to change very little
> > in the existing BoardSquare class.
> >
> > But it does mean I have to handle ALL hit testing and updating of the
> > BoardSquares manually. Which I was trying really hard not to have to
> > do.
> 
> Couldn't the "Smarter" widget still just be a top-level graphics item
> with a lot of children? Then set the scene rect to be static and handle
> scrolling by translating the top-level graphics item (based on some
> custom input handler).

In that case, all of the children will want to accept input, which will 
steal it from the parent. Making the input handling probably more complex 
than it needs to be.

> 
> The other option I could see to avoid having to write a fully custom
> widget would be to embed a sub-graphics view into the main graphics view.

Still the same input problem. If I want to scroll and zoom with regular 
input events, the "smarter" widget will want those events, while the 
children of those will want some of the same events as well.

In the end, I decided to just have a single widget, but re use the 
"GameBoardSquare" class mostly as is, so I can do hit testing against the 
items, as well as keep the paint method (but not actually add them to the 
parent widget). This way only one widget actually handles the input events, 
the GameBoard widget, and if it thinks an event is for one of the Square's 
it passes it on, rather than a GameBoardSquare passing the event back down 
in some hacky fashion.

> > Is a feature where an item is completely isolated from the scene
> > transformation and translation likely to be added to Qt? I think it
> > would be something that a lot of people would like very much.
> 
> I guess the use case of having scroll bars that only scrolled some of
> the graphics items was not considered to be important. Maybe it breaks
> user expectations of how scroll bars typically work, so having a
> different way of scrolling based on mouse or keyboard input (grouping
> all the scrollable items in a graphics item) might actually be
>  preferable.
> 


-- 
Thomas Fjellstrom
tfjellstrom at shaw.ca



More information about the Qt-interest-old mailing list