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

[Thomas Fjellstrom]

On Fri January 22 2010, Samuel Rødal wrote:
> ext Thomas Fjellstrom wrote:
> > On Fri January 22 2010, Samuel Rødal wrote:
> >> Basically the
> >> top-level item is just an invisible item whose bounding rect is the
> >> same as the combined bounding rect of the child items (game squares).
> >> Whenever you earlier scaled / scrolled the view itself you'd now do
> >> the same with the top level item. You might wish to use
> >> QGraphicsScene::setSceneRect() to control which part of the scene
> >> should be mapped to the view at any time.
> >>
> >> I don't think this way of doing things should be significantly harder
> >> than changing the view transformation.
> >
> > But how to actually handle the events is something else. Right now the
> > child widgets all accept mouse events, which means the parent widget
> > doesn't get them, so it can't know when a person is trying to scroll or
> > zoom.
> >
> > I'm not sure how to have both, selecting the game elements, AND letting
> > the game board accept events to handle scrolling and zooming.
> 
> Not sure I understand from where you're currently triggering scrolling
> and zooming. Does each game square currently tell the view it needs to
> scroll or zoom? If so, can't you keep the current design but instead
> tell the invisible game board item to scroll / zoom?

Sorry if I wasn't clear enough before.

Right now the scrolling happens due to the QGV's own scroll bar. Zooming 
would have (I haven't implemented it yet) been done with the scroll wheel 
for now (and touch events in the future).

Moving to keeping the scene's translation and transformation static would 
mean disabling the view's scroll bar, and either implementing my own, or 
scrolling by clicking anywhere on the "game board" and dragging the board 
around (which is how it _will_ work on touch based devices).

This means that both the game board, and the children game squares would 
both want to accept the same mouse events. Is that even possible? I imagine 
it might be possible to get it to work by cancelling the "mouse release" 
event IF the mouse was moved more than a few pixels, which theoretically 
should pass the event down to the game board, but that would make for some 
awkward scrolling. Maybe it would have to cancel "press" in the mouse move 
event if the mouse was moved more than a few pixels, and tell the square to 
ignore the release event in that case. But its starting to get a little 
messy and complicated.

> > I find it odd that your messages to the list aren't getting through
> > right away while mine are. Is there something up with the mailing list?
> 
> Looks like there's some kind of delay, yes, but I don't know what's
> causing it.
> 


-- 
Thomas Fjellstrom
tfjellstrom at shaw.ca