Mouse grabbing - Question for experts

[fullmetalcoder]

Is there anything preventing you from handling mouse events directly in the graphics view without messing with mouse grabbing?

[nish]

do not overlay a widget. Its overkill. Use an eventFilter

[Spitfire]

QGraphicsView can manage the mouse event so you don't need transparent overlay to do it.

What I would do is to make the items to register touch start/move/end and qgraphicsview to register touch move only.
now when user touches the screen item registeres the touch and if next action is release - then the song is played (signal emited etc).
if instead of release, next action is move, item registers it and shouldn't play the song on release (simple bool set to true on touch and to false on move will do, check the bool on release to know what to do).
this way touch-release will play a song, but touch-move-release will not.
last step is to implement scrolling in qgraphics view move event handler and you're good to go.

I hope that's not too vague and gives you my general idea (to mimic ios touch/scroll). I did something like that in js and it worked well.

[jfmartel]

Is there anything preventing you from handling mouse events directly in the graphics view without messing with mouse grabbing?

Maybe I failed to make this clear but this question was part of my (bigger) question. If there was a way for widgets in a view to get all mouse click-move-release events without having to grab the mouse (as soon as you accept() an event you grab the mouse) then my problem would be fixed.

---

Added after 6 minutes:

QGraphicsView can manage the mouse event so you don't need transparent overlay to do it.

What I would do is to make the items to register touch start/move/end and qgraphicsview to register touch move only.
now when user touches the screen item registeres the touch and if next action is release - then the song is played (signal emited etc).
if instead of release, next action is move, item registers it and shouldn't play the song on release (simple bool set to true on touch and to false on move will do, check the bool on release to know what to do).
this way touch-release will play a song, but touch-move-release will not.
last step is to implement scrolling in qgraphics view move event handler and you're good to go.

I hope that's not too vague and gives you my general idea (to mimic ios touch/scroll). I did something like that in js and it worked well.

I see exactly what you want to do and that happens to be what I also want to do. The problem is not if I use an overlay widget or not (I think). My problem is that if I grab the mouse events (accept() the mouse click event) then no other widget will receive the move and release events until the button is released. And in the other way, if a widget don't accept the click event then it will not receive the move and release events... I see now way whatsoever for all the widgets to receive all the events. And that is the core of my problem !

Thanks for your answer

[fullmetalcoder]

If there was a way for widgets in a view to get all mouse click-move-release events without having to grab the mouse (as soon as you accept() an event you grab the mouse) then my problem would be fixed.

Event filter?

[jfmartel]

Event filter?

Ok, I'll dig into that.

[jfmartel]

Okay,

Thanks all for your answers. With your help, I discovered the use of Event filters today and it will be very usefull in my Qt future

Once I understood how filters worked then what you said guys was right. Overlaying widgets was not necessary. I only filtered the usefull events and I get good control over the event propagation. It's a very clever system.

Thanks to all of you who took time to post.