GNOME Bugzilla – Bug 757530
GtkWindow reacts on maximize action even if it is fixed-width
Last modified: 2015-11-19 20:05:32 UTC
I try to maximize a Window using double-click on GtkHeaderBar, move to top or <Super>+<arrow up>. In case this window is fixed-width (e.g. Gnome-control-center's top window and many of its dialogs), I see this behavior: On X the window refuses to react on the maximize action. It still draws shadows around its edges. On Wayland the window reacts to this action. It will now be drawn top-left on the screen. It doesn't draw shadows any more.
Yes, on X11, the window manager knows exactly how much screen estate a maximized window would cover. The application sends a request to the WM to change its state to maximized, the WM may decide not to allow maximization if the window constraints do not allow for the expected size. Moreover, on X11, the window manager handles the double click on the window decorations (when the window manager decorates the windows, that doesn't apply to CSD). On Wayland, it's different, and I am not sure we can precisely determine what would be the size of the window once maximized. On Wayland or when using CSD, the application itself manages its decoration and header bar. gtk header bar will not show the maximize button if the window is not of type normal or if the window is not resizeable, but will still allow for double click action (to try) to maximize the window, which is inconsistent imho. So I'll post two patches: 1. Change gdkwindow-wayland to not allow for maximization if the window is constained to a smaller size than the monitor size (this is an approximation though, because the actual size of the window once maximized will most likely be slightly smaller that the monitor size because of the docks) 2. Fix gtkwindow to apply the same restriction on maximization that gtk header bar does for the maximize button, i.e. do not allow for maximization if the window in not of type normal or not resizeable.
Created attachment 314813 [details] [review] [PATCH 1/3] wayland: do not maximize a window if constrained If a window is constrained to a size smaller than the monitor size, maximizing that window will not resize the window to the expected size. Make sure the window can be resized to match the size of the monitor, and refuse to maximize the window if its constrains are smaller than the expected size once maximized. This is an approximation though, because the actual size of the window once maximized will most likely be slightly smaller that the monitor size because of the docks. _Note_ I am not entirely sure this patch is strictly necessary to address the issue reported in this bug 757530, it should work with just the next two patches alone.
Created attachment 314814 [details] [review] [Patch 2/3] wayland: apply maximized state only when possible The compositor might have configured the window to be either maximized or fullscreen while the window itself has size constrains that would prevent the window from being maximized or fullscreen. Check for the actual resulting size of the window after applying the new state and revert the state if the new state cannot be achieved.
Created attachment 314815 [details] [review] [PATCH 3/3] window: maximize on double click only if allowed GtkHeaderBar will not show the maximize button if the window in not of type normal or not resizeable. Use the same restriction for double-click actions as well.
Review of attachment 314815 [details] [review]: this makes sense to me.
Review of attachment 314814 [details] [review]: ::: gdk/wayland/gdkwindow-wayland.c @@ +1033,1 @@ } Is it ok to not ack configure ?
Review of attachment 314813 [details] [review]: ::: gdk/wayland/gdkwindow-wayland.c @@ +2057,3 @@ + &allowed_width, + &allowed_height); + Hmm, are you sure this can work ? Afaik, the window geometry (at least the window position) is largely fantasy, under wayland. And the margin you are using here is the large non-maximized margin, whereas an actually maximized window has no margin at all...
(In reply to Matthias Clasen from comment #7) > Review of attachment 314814 [details] [review] [review]: > > ::: gdk/wayland/gdkwindow-wayland.c > @@ +1033,1 @@ > } > > Is it ok to not ack configure ? Yes. According to the current spec it is Ok to drop all configure requests except the last one, but since there might already be a configure request on the wire when the client drops all but the last and acks that, I don't see how the server can disallow that ack anyway.
(In reply to Matthias Clasen from comment #8) > Review of attachment 314813 [details] [review] [review]: > > ::: gdk/wayland/gdkwindow-wayland.c > @@ +2057,3 @@ > + &allowed_width, > + &allowed_height); > + > > Hmm, are you sure this can work ? Afaik, the window geometry (at least the > window position) is largely fantasy, under wayland. Good point. Although we don't check for the positioning ourselves here, I reckon gdk_screen_get_monitor_at_window() does for us but I haven't check if that would actually work with a multi-monitor setup on Wayland, indeed. > And the margin you are > using here is the large non-maximized margin, whereas an actually maximized > window has no margin at all... Yes, the idea was to make sure the actual window content would fit the resulting area, either by removing the margins from the window or adding them to the expected size. Anyhow, I added this patch for the sake of completion, it's not required to fix this current issue, if we get attachment 314814 [details] [review] and attachment 314815 [details] [review] into gtk+ this is less likely to happen. Of course, if an app calls gtk_window_maximize() on a window which is not resizable (or not resizable enough) it will still fail on Wayland without attachment 314813 [details] [review] but it's a slightly less probable scenario (and one could argue that the app itself sets its window constrains so if the app tries to maximize a window while not allowing for it using constrains, it would be a bug in the app itself).
(In reply to Jonas Ådahl from comment #9) > (In reply to Matthias Clasen from comment #7) > > Review of attachment 314814 [details] [review] [review] [review]: > > > > ::: gdk/wayland/gdkwindow-wayland.c > > @@ +1033,1 @@ > > } > > > > Is it ok to not ack configure ? > > Yes. According to the current spec it is Ok to drop all configure requests > except the last one, but since there might already be a configure request on > the wire when the client drops all but the last and acks that, I don't see > how the server can disallow that ack anyway. Beside, if we ack the request without applying the changes to the state/size, the Wayland compositor reckons the configure was successful and will move the window to the top left corner (as it would if it was actually maximized), which is not what we want here as we didn't allow for maximization. So I reckon we shouldn't ack the request if we didn't apply it. The spec reads: When a configure event is received, if a client commits the surface in response to the configure event, then the client must make an ack_configure request sometime before the commit request, passing along the serial of the configure event. For instance, the compositor might use this information to move a surface to the top left only when the client has drawn itself for the maximized or fullscreen state. If the client receives multiple configure events before it can respond to one, it only has to ack the last configure event. A client is not required to commit immediately after sending an ack_configure request - it may even ack_configure several times before its next surface commit. The compositor expects that the most recently received ack_configure request at the time of a commit indicates which configure event the client is responding to.
(In reply to Olivier Fourdan from comment #10) > [...] > Anyhow, I added this patch for the sake of completion, it's not required to > fix this current issue, if we get attachment 314814 [details] [review] [review] and > attachment 314815 [details] [review] [review] into gtk+ this is less likely to happen. > > Of course, if an app calls gtk_window_maximize() on a window which is not > resizable (or not resizable enough) it will still fail on Wayland without > attachment 314813 [details] [review] [review] but it's a slightly less probable > scenario (and one could argue that the app itself sets its window constrains > so if the app tries to maximize a window while not allowing for it using > constrains, it would be a bug in the app itself). Actually, no, I'm wrong here. If an app calls gtk_window_maximize() it will translate to gdk_wayland_window_maximize() and we shall receive an event configure from the compositor, and we'll get a chance to deny it with attachment 314814 [details] [review] if the constrains do not allow for it. So we can forget about attachment 314813 [details] [review], it's not needed.