Refrain from resizing a maximized main window

[eumagga0x2a]

When loading or closing a video, Avidemux resizes the video widget first and then tries to resize the main window, which astonishingly succeeds on Linux even if the main window was maximized resulting in disturbing view depicted in http://avidemux.org/smif/index.php/topic,16955.0.html. Additionally, loading a HD video can sometimes lead to a ghost of the navigation toolbar painted across the video window.

The following simple patch swaps the order of the window and video widget resizing, which helps against the second issue, and avoids resizing the main window when maximized. It also increases the extra space accounting for the needs of the codec and navigation widgets, the current values are way too low on Linux with the fusion and GTK QT themes and German locale.

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 b0081cd..aefee79 100644
--- a/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp
+++ b/avidemux/qt4/ADM_userInterfaces/ADM_gui/T_preview.cpp
@@ -166,8 +166,16 @@ void  UI_updateDrawWindowSize(void *win,uint32_t w,uint32_t h)
displayW = w;
displayH = h;

-    videoWindow->setADMSize(w,h);   
-    QuiMainWindows->resize(w+218,h+100);
+    // Resizing a maximized window results in not refreshed areas where widgets
+    // in the maximized state were drawn with Qt5 on Linux, try to avoid this.
+    // TODO: Resize the main window on restore event.
+    if(!QuiMainWindows->isMaximized())
+    {
+        uint16_t extra_w=240; // take into account the width of the codec widget in px + some margin
+        uint16_t extra_h=240; // take into account the height of the navigation widget in px + some margin
+        QuiMainWindows->resize(w+extra_w,h+extra_h);
+    }
+    videoWindow->setADMSize(w,h);
#if 0

UI_purge();

This patch introduces a IMHO minor issue that restoring Avidemux window from maximized state makes it as big or small as it was prior to entering the maximized state: the sequence

• launch Avidemux
• maximise Avidemux window
• load a HD video
• restore the window

results in an Avidemux window as small as after the step 1, making it necessary for the user to resize the window manually.

[eumagga0x2a]

Maybe I should have added that this patch has been tested and confirmed working correctly on Fedora 24 with Xorg and on Fedora 25 with Wayland (well, probably Xwayland in case of Avidemux) and Xorg.

I had also recently a chance to test an official nightly on Windows 7, and though resizing while maximized doesn't result in that strange, highly broken view one gets on Linux, it does confuse the system, which still remembers the resized Avidemux window as maximized. This means that a fix is needed also there.

While the implementation of the part with two extra variables (which should be const anyway) extra_w and extra_h is surely expendable (218 and 100 extra added px in the current code are not enough on Linux though), I'm pretty confident about the remaining solution. I think that it brings benefit substantial enough to give it a go.

[mean]

Pushed, thanks

[eumagga0x2a]

Thank you very much, now it would be great to get some feedback how this patch works on Mac, a platform I don't have any access to.

[Jan Gruuthuse]

works nice on 16.04.1 LTS Unity & QT5, tested with 720p and with 1080i.

[Jan Gruuthuse]

On 14.04.5 a few pixels are missing on right-hand side of video. Tested with 720p and with 1080i. It is acceptable for me.

[eumagga0x2a]

The missing pixels depend on the (unknown) width of the codec widget. It is assumed that 240px would be enough most of the time. To make it fit, the code would have to query the width of the codec widget prior to resizing the window.

Does the patch reliably prevents contracting of Avidemux GUI on video load while maximized for you?

[Jan Gruuthuse]

4k screen: I never use avidemux on full screen.
1080i seems to be ok, it's only 720p that is still expanding when enlarging avidemux GUI by dragging side. Couple of pixels.