Questions about zooming QGraphicsView

[JovianGhost]

I've created a form with Qt Creator, on which I have a QGraphicsView object.
I'd like to be able to zoom this item by intercepting the the wheelEvent function, but I don't want to have to subclass QGraphicsView and override wheelEvent there, so instead I overrode wheelEvent in the parent frame:



void MyFrame::wheelEvent(QWheelEvent* event)
{
if (_view->underMouse())
{
if (event->delta() > 0)
_view->scale(2, 2);
else if (event->delta() < 0)
_view->scale(0.5, 0.5);
}
}


Where _view refers to my QGraphicsView object. This seems a bit clunky but it appears to work. Is there a better way of doing this?


Now the second question: although the above works, I notice that as soon as scroll bars appear in the QGraphicsView, then this functionality fails, and scrolling the mousewheel will instead cause the view to scroll. I presume this is because wheelEvent is being intercepted somewhere else, before my frame can handle it. Is there a way around this? I want the mousewheel to ALWAYS scroll the view.

[Lykurg]

but I don't want to have to subclass QGraphicsView and override wheelEvent there
Why not?


Where _view refers to my QGraphicsView object. This seems a bit clunky but it appears to work. Is there a better way of doing this?
Yes, subclass your view!;)


NI presume this is because wheelEvent is being intercepted somewhere else
Yes, by your view. That wouldn't be a problem if you would subclass your view. But as a workaround you can install an event filter on your view and handle the weel event there, or better do not handle it there so your function comes to play again.

[JovianGhost]

Why not?

Well, I suppose the main reason is that I want to keep all GUI-related design in the GUI editor. If I subclass QGraphicsView, then I have to manually code instantiation and adding it where I want it. I know it doesn't sound like a big deal, and actually sounds pretty silly, but the way I see it part of the benfit of having a WYSIWYG GUI designer is that you don't have to worry about this stuff anymore. Guess I'm just spoiled. :o


Yes, by your view. That wouldn't be a problem if you would subclass your view. But as a workaround you can install an event filter on your view and handle the weel event there, or better do not handle it there so your function comes to play again.

Well, I guess that's as good of an argument as any to subclass QGraphicsView.
If only I had a nickel for every time I had to subclass an existing class to make one minor change... :)

PS It worked, thanks!

[Lykurg]

Well, I suppose the main reason is that I want to keep all GUI-related design in the GUI editor. If I subclass QGraphicsView, then I have to manually code instantiation and adding it where I want it. I know it doesn't sound like a big deal, and actually sounds pretty silly, but the way I see it part of the benfit of having a WYSIWYG GUI designer is that you don't have to worry about this stuff anymore. Guess I'm just spoiled. :o
First, I am fine that you don't want to subclass!
But I always wonder why people don't want to do so. As for your WYSIWYG argument: You can promote a widget in designer. So you can use your subclass and in designer it behaves like a normal graphics view and sets all properties correctly to your prometed subclass.

[GimpMaster]

But as a workaround you can install an event filter on your view and handle the weel event there, or better do not handle it there so your function comes to play again.

I've tried going with the event filter route. It still seems to only emit the Wheel event when the scroll bar is at one of its extents.

*EDIT* I take that back. If I use the eventFilter from a QGraphicsView I only get the mouse wheel event when the scrollbar is at one end. However if I install and eventFilter for the QGraphicsScene I get the mouse wheel event when it is not scrolled at the top or bottom as a QGrahpicsWheel event. So I need to install an event filter for both?