GTK3 windows that are snapped to the edge of the screen don't return to their non-tiled state after restoring.

[pablo-888]

They remain squared and the shadows are gone. I didn't notice this before because I just happened to be using a square theme that didn't have any shadows to begin with. As a workaround I just set 'notifyClient' to never for now.

I thought it was weird because I remember seeing a video of it working on that feature's PR but then I noticed the demo was made with a GTK4 app (Nautilus) so I tried the same (gnome-todo/endeavour) and that one worked fine. Only GTK3 apps have this problem for me.

[Consolatis]

Personally I can't really test this as my gtk3 version is too old (it doesn't support the tiling notifications at all).
Maybe @ahesford could give it a shot, a good candidate for testing might be gtk3-demo.

[ahesford]

I can't reproduce this issue. My copy of Endeavour, from Void Linux, uses GTK4. I have several GTK+3 applications, including gtk3-demo, cheese, gedit, simple-scan and wdisplays. When I snap those windows to edges, rounded corners on client-side decorations do not disappear. When I drag the windows away from the edge, the shadows are still visible.

[pablo-888]

I think it's a GTK version thing. Arch uses 3.24.41 while Void uses 3.24.38. I downloaded 3.24.38 from the archives and sure enough it behaves like you described.

[ahesford]

Very interesting. I think the best long-term solution for labwc would be window actions that allow control over the tiling notification behavior of individual, misbehaving clients in addition to the global switch available now.

[jp7677]

Looking at Gnome/Mutter (45.4 on Wayland with Fedora 39, GTK3 3.24.41) on my machine, the snapping and unsnapping effects do work there correctly with GTK3 apps, whereas the same applications refuse to unset the snapping appearance on labwc. But no idea though if Gnome/mutter just carries a work around or handle that differently.

[jp7677]

This is the PR that introduced tiling support for GTK3 https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6629 released with GTK3 3.24.39

[Consolatis]

Looking at Gnome/Mutter (45.4 on Wayland with Fedora 39, GTK3 3.24.41) on my machine, the snapping and unsnapping effects do work there correctly with GTK3 apps, whereas the same applications refuse to unset the snapping appearance on labwc. But no idea though if Gnome/mutter just carries a work around or handle that differently.

A WAYLAND_DEBUG=1 log of the two might help here.

I have a feeling that this requires more investigation and thus might not make it into the next release. I'll keep the milestone around for now but we may adjust it to target 0.7.2 instead.

[jp7677]

Here are two log files, from labwc and Gnome, recorded with WAYLAND_DEBUG=1 tilix. What I did was snap, unsnap and close using keys. Let's hope this provides something useful.

labwc:
labwc.log

Gnome:
gnome.log

[Consolatis]

Hm..
labwc:

[2764987.072] xdg_toplevel@32.configure(1602, 1188, array[4]
[2766332.114] xdg_toplevel@32.configure(1720, 1404, array[20])
[2766660.096] xdg_toplevel@32.configure(1602, 1188, array[4])

gnome:

[2868914.608] xdg_toplevel@39.configure(1602, 1188, array[4])
[2869713.328] xdg_toplevel@39.configure(1720, 1408, array[16])
[2870191.705] xdg_toplevel@39.configure(1602, 1188, array[4]

Sadly, the WAYLAND_DEBUG output doesn't parse the array contents at all and just states its overall size. So we only know that both - labwc and gnome - are adding new states to the array. A single item has size 4 so in the labwc case it was 1 state (most likely activated) then 5 states (likely activated and the 4 tiled edges) then 1 state (back to only activated), whereas at gnome it was 1 state -> 4 states -> 1 state.

If you feel like spending some more time on this you could use an old toy project of mine that I used to learn about the wayland wire protocol instead of WAYLAND_DEBUG=1, that one doesn't parse arrays either but at least gives its content: https://github.com/Consolatis/wl_tee/

It can be called like WL_DEBUG_FILTER=xdg_toplevel.configure ./wl_debug.sh tilix

[jp7677]

mmh, your projects works on labwc, but bails out on Gnome :(

Client-0] connected
[Server-0] connected
[WaylandProxy] Got unhandled exception: ConnectionResetError: [Errno 104] Connection reset by peer
[WaylandProxy] Traceback (most recent call last):
[WaylandProxy]   File "./wayland_proxy.py", line 325, in <module>
[WaylandProxy]     data, fds = msg_receive(local_socket)
[WaylandProxy]                 ^^^^^^^^^^^^^^^^^^^^^^^^^
[WaylandProxy]   File "./wayland_proxy.py", line 178, in msg_receive
[WaylandProxy]     data, ancdata, msg_flags, address = connection.recvmsg(
[WaylandProxy]                                         ^^^^^^^^^^^^^^^^^^^
[WaylandProxy] ConnectionResetError: [Errno 104] Connection reset by peer

[jp7677]

PS: the only thing that got my attention in the gnome logs where gtk_surface1@40.configure_edges(array[16]), but don’t know if that is related.

[Consolatis]

PS: the only thing that got my attention in the gnome logs where gtk_surface1@40.configure_edges(array[16]), but don’t know if that is related.

Uh, I completely missed that! That is indeed some private GTK / Gnome protocol and could very well explain why it works on gnome but not on labwc. Maybe its really a bug in (older?) versions of GTK3 in that they don't restore the edges when untiled using the official xdg protocol.

[jp7677]

Based on https://gitlab.gnome.org/GNOME/gtk/-/blob/gtk-3-24/gdk/wayland/protocol/gtk-shell.xml?ref_type=heads#L55 I guess looks indeed like that.

[Consolatis]

Side note:

Wlroots used to have an internal workaround in that if a client didn't support tiling notifications wlroots just sent a fake maximized state (that for the most part has the same effect as tiled on all edges but may have subtle differences like showing an un-maximize button in the CSD). But AFAIR they removed that workaround and left it up to the compositors to either do the same or don't fake it.

This would not solve this issue though because here GTK claims to support the tiling notifications but apparently does not implement it correctly based on the evidence I saw so far.

[jp7677]

Hi @emilio , sorry for pinging you directly. Since you wrote https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6629 with other compositors than mutter in mind (well, according to the PR description) this might be interesting for you.

[emilio]

Sure, I can try to take a poke, I can repro this.

[emilio]

https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6952 is the fix for this. Ironically a related fix (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6742) which also affects gtk4 (https://gitlab.gnome.org/GNOME/gtk/-/merge_requests/6745) would've papered over this issue.

[jp7677]

Thanks a lot for directly addressing this, very cool!

[Consolatis]

@emilio great. Thanks!

Closing this as it will be fixed via a future GTK3 release.

[jp7677]

GTK3 3.24.42 has been released recently and with this version the corners return nicely rounded when un-tiling.

Now we just need the SSD corners to show (conditionally) the same behavior and all is beautiful consistent.