After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 726592 - W32: problems with CSDed windows
W32: problems with CSDed windows
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: Backend: Win32
3.11.x
Other Windows
: Normal normal
: ---
Assigned To: gtk-win32 maintainers
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2014-03-18 00:36 UTC by LRN
Modified: 2014-04-16 22:57 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
W32: correctly guess max window size from the size of the workarea of the screen it's on (1.75 KB, patch)
2014-04-10 20:10 UTC, LRN
reviewed Details | Review
W32: correctly guess max window size from the size of the workarea of the screen it's on (1.90 KB, patch)
2014-04-11 09:06 UTC, LRN
committed Details | Review

Description LRN 2014-03-18 00:36:05 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.
Comment 1 LRN 2014-04-04 09:48:53 UTC
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.
Comment 2 LRN 2014-04-10 20:10:36 UTC
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.
Comment 3 LRN 2014-04-10 20:14:59 UTC
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.
Comment 4 Ignacio Casal Quinteiro (nacho) 2014-04-10 21:12:00 UTC
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?
Comment 5 LRN 2014-04-11 05:18:44 UTC
(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...
Comment 6 LRN 2014-04-11 09:06:28 UTC
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
Comment 7 Matthias Clasen 2014-04-13 21:27:22 UTC
Review of attachment 274071 [details] [review]:

ok
Comment 8 LRN 2014-04-14 00:30:09 UTC
Would this qualify as a bugfix? I could try to merge it into stable brakches as far back as possible.
Comment 9 Matthias Clasen 2014-04-15 23:28:39 UTC
sure, thats fine
Comment 10 LRN 2014-04-16 22:41:21 UTC
Attachment 274071 [details] pushed as 42ee237 - W32: correctly guess max window size from the size of the workarea of the screen it's on
Comment 11 LRN 2014-04-16 22:57:06 UTC
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.