Mirroring MainWindow to a second QMainWindow

L Koziarz

I'd like to be able to scale the main application window down below a factor of 1.0. (In case you're curious, I'm trying to show a 480x800 portrait UI that runs on an embedded target on my development PC, but the PC only has a 768px high display).

Since QT_SCALE_FACTOR doesn't support values less than 1.0, I'm trying to mirror my application's QMainWindow into a second QMainWIndow.

So far it's working, but when I take mouse events in the secondary window, scale them to the size of the primary window, and then post them to the primary MainWindow's widget, I lose mouseRelease events.

From installing event filters and watching mouse clicks travel across, it looks like my primary window is grabbing the mouse when the mousePress event is posted from the secondary.

How can I keep the secondary window to hold the mouse so it sees the release and then passes the release event to the primary?

Or is there another way to remote display QMainWindow?

jsulm

@L-Koziarz Why do you want to scale your UI instead of resizing it?

L Koziarz

@jsulm The target application is an embedded UI running on a 480x800 LCD in portrait mode. For customer demonstration and development purposes, I'd like the application to also work on Win32/64. In previous projects this hasn't been a big problem, but in this particular case we have some laptops that do not have an 800px high screen.

Resizing and/or scrolling the MainWindow is certainly an option, but doesn't allow one to fully see the screen and/or manipulate objects in the corners.

mrjj

Hi
Just as a note. on amd/nvdia , you can add custom resolutions.
https://www.monitortests.com/forum/Thread-Custom-Resolution-Utility-CRU

Unless the laptop cant actually display 800 in height. As in too high. :)

L Koziarz

Hi mrjj,

That's indeed a possible solution, and one I wish Microsoft was including in all versions of Windows. Apple has had this for what, nearly a decade now?

Unfortunately this Windows build might go out as a sales/training tool into a field of machines with unknown hardware. Scaling the display on a plain box is my only hope of success.

mrjj

@L-Koziarz
Hi
Well only the good old and dead Win XP cannot do it even if drivers
support it. That said, not all , older intel onboard chips would use
it. Even it should support it Windows wise.
(win 7 was tested on older laptops)

So I agree deployment on unknown hardware and using
EDID override might end being a mess/nightmare.

I was wondering if you tested with
http://doc.qt.io/qt-5/qwidget.html#grabMouse
Its docs says
"Qt grabs the mouse when a mouse button is pressed and keeps it until the last button is released."
Which does sounds like what you are seeing. ?

L Koziarz

QWidget::grabMouse doesn't seem to work correctly when posting a mouseEvent to another QWidget after the call to grabMouse(). The side effects are really bad. This is 5.9 on Win64 desktop.

mrjj

@L-Koziarz
Did you try to call releaseMouse() ?
And then forward event?
Just asking. Did not test if that is even worse :)

L Koziarz

The grab and release sequence falls apart when generating a new press into another widget.

I'm giving up on this approach and telling the client that Qt scaling will never be able to zoom out.

mrjj

@L-Koziarz
Yep its sounds somewhat convoluted
but never the less - exciting approach .
I wish it had worked as prof of concept but it seems there are issues.