@JoeCFD said in mouseMoveEvent not being called:

do you have the following line in the constructor of class MouseTrackingFrame?
installEventFilter( this );

No, the install_filter(...) function being called from MouseTrackingFrame::postSetup() does that. But I'm not sure if it has any effect - I saw a post somewhere which said Qt ignores when the widget itself is passed to installEventFilter(...)

@Eric-Singer Because my suggestion is not to limit the size of the parent but rather to limit what the layout reports as the minimum size required. minimumSize() returns the minimum amount of space the widget needs to provide so that the layout can fit all the widgets inside it.
maximumSize() is the size beyond which the layout can't reasonable grow the widgets inside.

Maximum size is not useful for this case. Your problem is that the parent widget grows too much and it grows because the minimum size of the layout grows i.e. the minimum amount of space required to lay out the widgets inside grows.
If you return a fake limit, one that is smaller than the sum of all the widgets inside, the parent will be able to keep its size despite all the children in the layout not fitting (visually they will be cropped). You could, for example, return the minimum of the base implementation's value that calculates it based on the content size and some constant value of yours, beyond which you don't want to grow.

To be honest that's pretty much what a scroll area does and I think the suggestion given by @SGaist is a better one as it already does that work for you.

@SGaist I tried the Qt 5.12.6 and it did the trick! Thanks.

But interestingly, the title of the main application is no longer scaled by "Make text bigger" setting but the dockwidget ones does. I guess that there is an intention not to scale the main title. "Make everything bigger" setting does scale everything properly now except the titlebar height of only the main application looks not enough for the enlarged font size. I will give qt5.14 a try as well.

@Dagginio
Hi
just call update() to have it refresh when "status" changes.

-Do I have to remove that blue frame before I paint a grey one?
depends if you have autofillbackground on widget on.
in that case it will be cleared default.
else u might have to. try without and see

@McLion You can use layouts for those labels

hi
normally you would not allow directly accesses to UI class from outside
as then all of the program know you have a QFrame in there.

The better way is simple to create public function
that sets the data u need in the class that owns
the UI

say like
public:
SetSugarViewData( QString Name );

and in cpp you implement it and there u can use
ui->SugarView

Then main will talk to "sugerview" via the public functions and has no need to have access to UI->
directly.

Thank you.

Hi Guys, It works. I forget to remove
...
else {
return false;
}

in bool MFrame::event(QEvent* e).

The function "bool MFrame::event(QEvent* e)" returns QFrame::event(e) is the fix.

Thanks a lot.

@Jakob
well if FrameShadow is not plain
it does nothing so first i though it didn't work either.

Thanks for the reply. :D
self.sender() get me button that called function, that should be enough for now.
No, I haven't seen QML, I will definitelly check it out.
Thank you

@sohyun

oh, so it was not the image that was broken?
super
Nice day to you too

Hi and welcome
Many ways to do this, but here is my suggestion.

Add a signal to your graphicview class

signals: void MWheelActivated(bool ZoomIn);

and hook it up to a slot in your mainwindow with the connect function.
http://doc.qt.io/qt-5.5/signalsandslots.html

then in GraphicsView::wheelEvent(QWheelEvent *e)
you
emit MWheelActivated ( (e->delta() > 0));
and No zooming here!

Then in mainwindow slot

mainwindow:: MWheelActivated ( bool ZoomIn ) { if ( ZoomIn ) { view1->zoomIn ( 6 ); view2->zoomIn ( 6 ); } else { view1->zoomOut ( 6 ); view2->zoomOut ( 6 ); } }

Hope it helps.