Qt5: the content of a maximized window "unmaximises" on video start

[mean]

Works for me, linux & windows
??

[mean]

ah no, indeed it does not fix completely the issue

[Jan Gruuthuse]

QT5 on 16.04.1 LTS 64-bit: small issue remains:
closing the video, the worksurface (canvas) is not cleared.
Loading a new video still leaves old imprint on worksurface.
see:
close video screenshot 359 Kb
load new video screenshot 329 Kb

[eumagga0x2a]

Not trusting my testing from yesterday I did a clean build today and can confirm that 855d28f fixes none of the resizing issues. Especially bad: with a FullHD display, Avidemux window is not big enough to show the bottom part of a HD (1280x720) video upon loading the video (this is probably a Qt limitation). To see the hidden rest, a user resizes the window, pulls the right bottom corner down and to the right. Now she starts playback... and the window immediately resizes itself back, invalidating her efforts.

I really wish I were capable to think and speak C++ now, but even plainly commenting out the both calls to admPreview::setMainDimension() at https://github.com/mean00/avidemux2/blob/master/avidemux/common/gui_play.cpp#L149 and https://github.com/mean00/avidemux2/blob/master/avidemux/common/gui_play.cpp#L233 improves the behavior of Avidemux, solving this particular scenario (at the cost of the slider in the navigation bar flashing weirdly once forth and back on playback start; the length of the jump is equal to the already reached play position p, as if it were doing a seek to p*2 and back).

For a real solution, Avidemux should IMVHO query if its window is maximized first; if true, then don't do any resizing at all; else resize itself and the window as good as it gets on video load and on zoom change only.

[mean]

It fixes the following :
Start with a full HD vid, it will be zoomed out 1:2
Go back to 1:1 and hit play

[eumagga0x2a]

I'm sorry, but I failed to find any difference in behavior between https://github.com/mean00/avidemux2/commit/80e4934a9dfafbd5c3411bd34d901dcfcad045a8 ([Qt] 2nd part ...) and https://github.com/mean00/avidemux2/commit/680adad61060f7e6b41de3932afadb49387b9a2e ([misc] Cleanup ...).

It fixes the following :
Start with a full HD vid, it will be zoomed out 1:2

Yes, it gets zoomed out to fit into the screen, and the bottom and the right part of the video are cut off on my FullHD display as the window is limited to max. 2/3 of the display dimensions (this is expected).

Go back to 1:1

The window expands to the full space of the monitor, the navigation toolbar overlays the bottom part of the video.

and hit play

The navigation toolbar collapses out of sight, the video plays. There are two ways to bring it back to reach the buttons again: forcefully pull the separator between the toolbar and the video display all the way up or maximise and then unmaximise the window (keyboard shortcuts still work, of course). The previous Avidemux revision did exactly the same.

[mean]

Not on windows or kde

[eumagga0x2a]

I've retested on Xfce and the behavior with xfwm4 differs from mutter (gnome-shell) only in one point: the navigation toolbar doesn't overlay initially the bottom part of the video to fit into the view like it does on gnome. The window expands beyond the bottom edge of the display and can be dragged up and around with Alt+mouse (on gnome: Super+mouse; I forgot about this feature while testing on gnome-shell lately). Still, the initial size of the window doesn't allow the bottom part of the video be seen, and when resized manually, the window geometry snaps back on every change of playback mode (which is the core issue this bugreport is about).

I'm somewhat at a loss. Do you prefer the current logic that Avidemux resets the window geometry on playback start and stop?

[Jan Gruuthuse]

Are we taking in to account that the available video surface (blueish) of avidemux is smaller then the avidemux window?
Avidemux window size - minus:
- from width x pixels on left handside (redish)
- from hight
-- text menubar & Main toolbar (dark greenish, top)
-- Navigation bar (light greenish, bottom)

Most of the times the available video surface is smaller then the actual video size
on a 4k (3840 x 2160) monitor, you can't display a full 4k (3840 x 2160) video (100%) in to the avidemux video surface.


Just in case we are taking/using the wrong values making the math?

[eumagga0x2a]

I'm not sure if this is the correct approach, but adding 18 more pixels to the width in QuiMainWindows, which is derived from the size of videoWindow of the main window (I'm sorry, just learning to read the language) unhides the rightmost part of the video and gives it a nice margin, aligned with the right edge of the VU meter, so that it looks just rightâ„¢:

Code Select Expand


diff --git a/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp b/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp
index cc55d22..bb5c274 100644
--- a/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp
+++ b/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp
@@ -167,7 +167,7 @@ void  UI_updateDrawWindowSize(void *win,uint32_t w,uint32_t h)
displayH = h;

     videoWindow->setADMSize(w,h);   
-    QuiMainWindows->resize(w+200,h+100);
+    QuiMainWindows->resize(w+218,h+100);
#if 0

UI_purge();

The patch helps neither with the height limits of the Avidemux window when loading a 1280x720 video on a 1920x1080 screen nor with the resizing behavior nor with Avidemux not taking into account the maximized state of the window.

To demonstrate the effect of the patch, I attach a test video consisting just of a still image of rectangle with 3 concentric red frames, each 8px wide with 16px wide gaps inbetween and silence.

[eumagga0x2a]

Confirming that resizing on toggling playback has been fixed by https://github.com/mean00/avidemux2/commit/8987c1d95e2a9907a4ae01943caf9766ac814c4c, thanks a lot! Just the issue with resizing on video load when maximized remains.

What do you think about the window width tweak?

[eumagga0x2a]

What do you think about the window width tweak?

Please disregard the question, I already see that this approach can't be correct as it fails if the width of the codecWidget is pushed beyond the minimum width of 203px by localized lables.

[mean]

The window should resize correctly by itself, but for whatever reason it does not
Furthermore, the behaviour is different depending on the window manager
(Kde/Gnome/Windows/OSX)

I havent found a "correct" way to do it atm