Windows can't be resized and move properly in some contextes

[elinorbgr]

Follow up from the discussion in rust-windowing/glutin#577

[elinorbgr]

@Binero : can you provide the output of running the example with WAYLAND_DEBUG=1 set in the environment, and trying to resize / move the window ?

[Binero]

Still on v0.2.2. It does seem Mutter is sending the correct events. A simple grep for resize or move does yield results.
log.txt

[Binero]

I have also noticed that when focussing on the window, causes it to shrink by a bit, while loosing focus causes it to grow a bit bigger. I thought this behaviour was intentional, but looking at simple_window.rs, I cannot find such behaviour defined, so I am guessing it's a bug as well. I tried making a screencast, but gnome-shell would segfault.

[elinorbgr]

Hmm, the program is indeed sending the resize and move events in your log file:

[2257523.322]  -> wl_shell_surface@20.resize(wl_seat@7, 354, 8)

[2258723.446]  -> wl_shell_surface@20.move(wl_seat@7, 366)

[2261735.693]  -> wl_shell_surface@20.resize(wl_seat@7, 388, 8)

[2263148.017]  -> wl_shell_surface@20.resize(wl_seat@7, 396, 8)

For some reason, mutter seems to ignore them. I'm going to check if there's some subtlety in the protocol definition I missed regarding them.

Also, regarding the grow/shrink effect, well mutter is apparently sending configure events with varying sizes when the cursor enters/leaves:

[2258007.997] wl_shell_surface@20.configure(0, 272, 160)

[2258334.899] wl_shell_surface@20.configure(0, 272, 152)

[2259973.444] wl_shell_surface@20.configure(0, 272, 160)

[2260238.223] wl_shell_surface@20.configure(0, 272, 152)

[2262416.639] wl_shell_surface@20.configure(0, 272, 160)

it seems to fluctuate of 8 pixels in height. Is it what you observe?

[Binero]

That does sound about right. I must also add, when going into the activities screen in GNOME, the window decorations do not get rendered.

[elinorbgr]

Okay, I've more insight about this.

It appears that mutter does not fully support the wl_shell interface. Which is understandable, as it's mostly considered deprecated nowadays in favour of xdg_shell

However, the support of xdg_shell in wayland-client is currently blocked on the static_recursion feature gate ( see rust-lang/rust#29719 ).

So, if this bug is indeed the consequence of mutter's lack of support of wl_shell, there is little I can do about it for now, sorry.

[Razican]

Could using server-side decorations help? https://blogs.gnome.org/fmuellner/2015/01/30/a-small-note-on-window-decorations/

[elinorbgr]

Having server-side decorations would make all this much more easy: the client just wouldn't have to worry about them at all (and this crate would not really be needed).

However, the trick is that, afaik, there is not yet any mechanism for the client & server to negociate which on of them will do the decoration drawing. Some wayland compositors decided it's the client's job, while some others decided they'll do it. But I don't know of a standard way for a client to ask the compositor to draw its decorations (or if there is one and you know about it, I'd really like to hear about it).

[elinorbgr]

Ideally, wayland-window would draw decoration only if the compositor doesn't already draw them and it's not a decoration-less environment (like a tiling wm).

[Razican]

I have not studied the protocol, but seems that at least both Kwin and Mutter have server side decorations optional. The article I linked above is for Kwin, and this is for Mutter. Not sure if it's standard but maybe it can be a start.

[elinorbgr]

You linked two times to article for Mutter actually, and maybe I'm missing it, but I don't see what in this article seems to imply that mutter has server-side decorations fro wayland clients.

Actually, the gnome wiki seems to imply the opposite:

Under Wayland, it is preferred that clients render their own window decorations. Since gnome-shell will need to keep support for decorating X clients, it would be good if GTK+ and gnome-shell could share the css theming. Reads to me like gnome-shell will only support server-side decoration for X clients, not wayland.

Kwin has indeed followed the path of server-side decoration, and I think has a internal Qt protocol for advertizing wether decorations should be client or server side. This protocol could probably be integrated in wayland-window, to use server-side decorations on KWin.

[elinorbgr]

I think this is the protocol of KDE : https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml

[Razican]

Sorry about the first link, this was the article talking about Kwin server-side decorations.

I don't see what in this article seems to imply that mutter has server-side decorations fro wayland clients.

You are right, the article was explaining how server side decorations were going to be similar to client side ones. The thing is that when talking about server side decorations I thought it was talking about Wayland, but it wasn't.

[elinorbgr]

This is quite old, and other reports seem to indicate that the situation with mutter has improved (possibly mutter-side or with the various improvements to wayland-window), so I'll close this.

Feel free to open a new issue if some of these problems are still here.