Avidemux Forum

Windows + arrow keys are maximize/snap hotkeys.
The usual way to move a window is by dragging the titlebar, however in this case it could be completely inacessible if the taskbar is at the top of the screen. This would be uncommon.

I'm seeing a different issue with portrait mode sources larger than the screen. This is with the window maximized so it is a zoom issue: the image gets stretched (wrong display AR) when using 1 or 2.

Quote from: butterw on May 17, 2021, 02:25:42 PMThe usual way to move a window is by dragging the titlebar, however in this case it could be completely inacessible if the taskbar is at the top of the screen.

Exactly the problem addressed by the feature of many window managers on Linux to allow to grab and drag a window at any point, not only at the titlebar = a titlebar pushed out of reach is a serious usability issue for Windows. Regarding taskbar at the top, I'll need to recheck the window repositioning code (when Y axis is counted by Qt from the physical top edge rather than from the bottom edge of the top-placed taskbar, we have a problem), this possibility was definitely never considered during development and testing.

Quote from: butterw on May 17, 2021, 02:25:42 PMI'm seeing a different issue with portrait mode sources larger than the screen. This is with the window maximized so it is a zoom issue: the image gets stretched (wrong display AR) when using 1 or 2.

I cannot reproduce this issue on Linux (tried with a portrait-mode 4k sample on a FullHD display), will need to recheck on Windows. However, if a zoom level is too high for the picture to fit into available space, the result will be broken this way or the other. I don't know whether it is worth the effort.

Quote from: eumagga0x2a on May 17, 2021, 04:26:51 PM

Quote from: butterw on May 17, 2021, 02:25:42 PMThe usual way to move a window is by dragging the titlebar, however in this case it could be completely inacessible if the taskbar is at the top of the screen.

Exactly the problem addressed by the feature of many window managers on Linux to allow to grab and drag a window at any point, not only at the titlebar = a titlebar pushed out of reach is a serious usability issue for Windows. Regarding taskbar at the top, I'll need to recheck the window repositioning code (when Y axis is counted by Qt from the physical top edge rather than from the bottom edge of the top-placed taskbar, we have a problem), this possibility was definitely never considered during development and testing.

You might need platform specific code to handle Windows correctly. The Win10 taskbar is always on top (I have it on the left side of screen).

Quote from: eumagga0x2a on May 17, 2021, 04:26:51 PM

Quote from: butterw on May 17, 2021, 02:25:42 PMI'm seeing a different issue with portrait mode sources larger than the screen. This is with the window maximized so it is a zoom issue: the image gets stretched (wrong display AR) when using 1 or 2.

I cannot reproduce this issue on Linux (tried with a portrait-mode 4k sample on a FullHD display), will need to recheck on Windows. However, if a zoom level is too high for the picture to fit into available space, the result will be broken this way or the other. I don't know whether it is worth the effort.

Wrong AR looks ugly. The AR issue also persists to some extent after you've zoomed back out so that the image fits in the screen.
Needs reproducing, figuring out and should be easy to fix.


 

I see, the problem with wrong AR when zoomed picture becomes too big to fit into available space in Avidemux window affects the unaccelerated Qt output only (i.e. it is impossible to draw stuff larger than canvas). All other outputs are fine, so no big deal.

Regarding Y with the taskbar at the top (at the top edge of the screen), Qt indeed counts from the screen edge, which results in the titlebar hidden behind the taskbar. The same probably applies to the setup with taskbar at the left.

The collision with the taskbar should be fixed by [1] + [2], thank you for your report.