I had a patch for that, lemme see if I can find it...

Ah right, here it is...

It was attachment 314814 [details] [review] in bug 757530 - It needs a rebase most likely as this code has changed since then, and probably some work as well, but the idea is that in Wayland, the compositor doesn't have any hint what the size limit a window may have as this is handled entirely by the client, so the compositor cannot tell whther or not a window can be maximized/fullscreened beforehand...

So the client (ie gtk+ in this case) has to adjust its state if it doesn't match. Or else you'll need an xdg-shell addition to give the compositor a hint, but this was not accepted in the past (Was just dicussing this with Jasper yesterday on irc...)

At the end of that bug, you said: forget about that patch, it's not needed.

Now it is needed after all ?

(In reply to Matthias Clasen from comment #3)
> At the end of that bug, you said: forget about that patch, it's not needed.
> 
> Now it is needed after all ?

It was not needed for the original issue in bug 757530 in its initial description.

There are two slightly different issues, one is the app requesting to fullscreen/maximize state by itself, although its own constraints wouldn't allow for it, that was bug 757530 which was addressed with attachment 314815 [details] [review] (ie teach gtk+ not to try to switch its state to maximized if the window cannot).

There is another issue that I found out while working on bug 757530 which is with the Wayland compositor trying to switch a window to fullscreen/maximized while the window itself should not be allowed (again, due to its constraints), this would be this bug 764413 here instead, and attachment 314814 [details] [review] was to address this (other) particular issue - As attachment 314814 [details] [review] did not really reached a consensus, I preferred to move forward as this wasn't required for bug 757530.

The problem with Wayland is that we don't have a way for the client to tell what should be the maximum size if a given window, so the compositor might always try to maximize/fullscreen a window, and its then up to the client to deny the change.

Either we take the approach followed in attachment 314814 [details] [review] or we (try to) add some hints[*] in xdg-shell that would allow an application to tell the compositor that some window states such as maximized/fullscreen should not be possible.

[*] by the lack of a better word here, some people do not like the word "hint" for this and would avoid it, but I use it here as this is what X uses so we have a broader common understanding...

After further discussion on irc on #wayland, it seems there is a need for a max_size hint so that the compositor can allow/disallow maximize/fullscreen transition, draw an accurate animation etc.

https://patchwork.freedesktop.org/series/5270/

Created attachment 325360 [details] [review]
[PATCH] wayland: obey configure event if maximized/fullscreen

While discussing the possiblity to add an max size hint to xdg-shell on irc, I have been pointed out to the current xdg-shell specification that states that if the surface is maximized or fullscreen, the window geometry specified in the configure event _must_ be obeyed by the client, which gtk+ doesn't (thus this bug):

https://cgit.freedesktop.org/wayland/wayland-protocols/tree/unstable/xdg-shell/xdg-shell-unstable-v5.xml#n345

      <entry name="maximized" value="1" summary="the surface is maximized">
	<description summary="the surface is maximized">
	  The surface is maximized. The window geometry specified in the configure
	  event must be obeyed by the client.
	</description>
      </entry>
      <entry name="fullscreen" value="2" summary="the surface is fullscreen">
	<description summary="the surface is fullscreen">
	  The surface is fullscreen. The window geometry specified in the configure
	  event must be obeyed by the client.
	</description>
      </entry>

Therefore, this bug would be a bug in the application (ie gtk+) that doesn't resize to the given size.

This patch makes it so that the given maximize/fullscreen size is obeyed, gnome-calculator now maximize properly :-)

But I still reckon a max size hint would be beneficial to let the compositor know that the window should not be resized to a greater size that specified, so even if we fix this by becoming in-line with the xdg-shell specification, we might want to also add the max size request to xdg-shell (if it ever reaches consensus on the ML).

Created attachment 325499 [details] [review]
[POC PATCH gtk+] wayland: add set preferred size limits to gtk-shell

This is a proof of concept (i.e. do not push), it adds set preferred size limits to gtk-shell.

This patch is for gtk+

Created attachment 325500 [details] [review]
[POC PATCH mutter] wayland: add set preferred size limits to gtk-shell

This is a proof of concept (i.e. do not push), it adds set preferred size limits to gtk-shell.

This patch is for mutter

Created attachment 326475 [details]
Test program

This simple reproducer is to demonstrate the need for attachment 325360 [details] [review] independently of the min/max addition to xdg-shell v6.

Even on X11, mutter will maximize windows that have a max size and a min size set.

Basically, on X11, what mutter does is to check if the window is resizeable or not. If the window is resizeable, it can be maximized or fullscreened, even if the specified max size is actually smaller than the available workarea.

mutter reckons a window is not resizeable if min == max. If min < max, it can be maximized for mutter (other window managers might behave differently, but that's not the point here).

 1. Save and build the attached program
 2. Start a GNOME on X11 session
 3. Run the reproducer in X11

Notice that the window cannot be resized manually to the full size of the monitor, yet moving it toward the top edge of the monitor and mutter will happily maximize the window.

Assuming this is the expected and desired behaviour, we need attachment 325360 [details] [review] in gtk+ to have the same in Wayland, even with the min/max size hint added to xdg-shell (which have now been pushed in xdg-shell v6 btw).

Other possbily relevant discussion:
https://lists.freedesktop.org/archives/wayland-devel/2016-April/028266.html

Created attachment 326535 [details] [review]
[PATCH wayland-procols] add min/max size requests to xdg-shell unstable v5

OK, this is cheating, the sole purpose of this patch is to add min/max size requests to xdg-shell unstable protocol v5 so I can prepare the patches for gtk+ and mutter without adding support for all of xdg-shell unstable protocol v6 (naughty, I know...).

So, to make it clear, this patch is not for merging (min/max have already been merged upstream in xdg-shell unstable protocol v6), this is just to test the two following patches for gtk+ and mutter without breaking everything.

Created attachment 326536 [details] [review]
[PATCH gtk+] wayland: add min/max size from xdg-shell v6

Not to be merged, at least not until xdg-shell unstable v6 becomes official.

Created attachment 326537 [details] [review]
[PATCH mutter] wayland: add min/max size from xdg-shell v6

Not to be merged, at least not until xdg-shell unstable v6 becomes official.

Created attachment 333874 [details] [review]
[PATCH gtk+] wayland: add min/max size from xdg-shell v6

Patch rebased on top of https://github.com/jadahl/gtk.git :wip/xdg-shell-unstable-v6

Review of attachment 333874 [details] [review]:

looks ok to me (once xdg-shell v6 lands)

Comment on attachment 333874 [details] [review]
[PATCH gtk+] wayland: add min/max size from xdg-shell v6

(In reply to Matthias Clasen from comment #15)
> Review of attachment 333874 [details] [review] [review]:
> 
> looks ok to me (once xdg-shell v6 lands)

attachment 333874 [details] [review] pushed as commit 9f57fe9 - wayland: add min/max size from xdg-shell v6

For the record, I made one change/fix before pushing, the patch was testing xdg_surface not being NULL whereas it should have been xdg_toplevel (that was a leftover of the previous implementation before xdg-shell v6)

Note: It needs the patch from bug 770226 in mutter for the min/max to be effective.

*** Bug 771413 has been marked as a duplicate of this bug. ***