GNOME Bugzilla – Bug 726592
W32: problems with CSDed windows
Last modified: 2014-04-16 22:57:06 UTC
1) Undecorated windows (gtk3-demo, all dialog boxes) have no borders, thus they can't be resized (except the ones that have that ugly corner widget - they can be resized by dragging the corner) 2) Undecorated windows have no visible borders, thus they tend to blend into background (and W32 WM does not dim other windows when transient dialog is shown, which would have mitigated the problem somewhat, if W32 WM did that) 3) Undecorated windows don't have rounded corners, thus they look ugly 4) Undecorated windows that can be maximized (gtk3-demo) do not calculate new window size correctly, covering the whole desktop (including the area covered by the taskbar). While covering the whole desktop (even the taskbar) can be useful in certain cases, this is not the usual behaviour on W32.
Update on this: (1) happens because there's no style for CSDs. If one is introduced (say, by copying CSD style from Adwaita or Raleigh), windows do receive borders (specifically - 0-wide border, but non-zero margin is enough). (2) is also fixed by this, as CSD theming includes a window shadow. The problem is that window shadow requires RGBA GDK windows, which is what bug 727316 is about. Without that bug fixed, windows with shadows are drawn as if they had a thick, opaque black border around them. (3) is also fixed by this (there are some fine points about getting the background for buttons and background colors for title-bar right, but rounded corners are doable) (4) is not fixed by this. This does need C code, i think.
Created attachment 274035 [details] [review] W32: correctly guess max window size from the size of the workarea of the screen it's on Get monitor on which the most of the window is located (nearest monitor if window is not on screen), get its work area (area not occupied by taskbar or any other bars) and use that for maxsize. Previous default of 30000 meant that windows maximized onto full screen, even covering the area where taskbar is.
Attachment 274035 [details] fixes the point 4 of the original report. Points 1-3 are fixed by a patch from the bug 727316. This fix for point 4 is independent from CSDs (it mostly affects CSDed windows, since SSDed windows' maximization is usually handled by the WM) and RGBA windows stuff and can be pushed independently.
Review of attachment 274035 [details] [review]: See comments. ::: gdk/win32/gdkevents-win32.c @@ +3086,3 @@ + gmi_succeeded = GetMonitorInfo (winmon, &moninfo); + + if (gmi_succeeded) since gmi_succeeded is used just here then I'd just do: if (GetMonitorInfo (...)) @@ +3093,3 @@ + else + { + mmi->ptMaxTrackSize.x = 30000; any idea why this magic number? should we put a comment about it?
(In reply to comment #4) > @@ +3093,3 @@ > + else > + { > + mmi->ptMaxTrackSize.x = 30000; > > any idea why this magic number? should we put a comment about it? No, just a big number, i guess. In another place (related to size calculation) GTK uses 10000...
Created attachment 274071 [details] [review] W32: correctly guess max window size from the size of the workarea of the screen it's on Get monitor on which the most of the window is located (nearest monitor if window is not on screen), get its work area (area not occupied by taskbar or any other bars) and use that for maxsize. Previous default of 30000 meant that windows maximized onto full screen, even covering the area where taskbar is. v2: Removed not-very-usable intermediate variable, added a comment about 30000
Review of attachment 274071 [details] [review]: ok
Would this qualify as a bugfix? I could try to merge it into stable brakches as far back as possible.
sure, thats fine
Attachment 274071 [details] pushed as 42ee237 - W32: correctly guess max window size from the size of the workarea of the screen it's on
Attachment 274071 [details] pushed as 6015bef into gtk-3-12 and as 2315030 into gtk-3-10 I decided not to go further, although googling for gtk_windows_maximize + win32 + fullscreen gives results that go as far back as 2008 at least. It may even affect gtk+-2.x. Merging this into 2.x is not a good idea without extensive app compatibility testing, which i just can't do. Since points 1-3 are covered by bug 727316, and point 4 was just fixed, i've marked this bug 726592 as fixed as well.