riverwm
River sets the xdg toplevel tiled state for all views not in the CSD filter, even floating ones
I implemented this early on in river's development mostly as a work around for the fact that GTK does not support xdg-decoration (See #24). Setting the tiled state causes GTK to get rid of it's client side shadows and makes the borders river draws look far less out of place.
However, setting the tiled state for floating views isn't really correct, and is known to cause minor issues with mpv, which is well behaved and restricts its functionality based on the tiled state: #451.
To fix this situation, I propose the following:
- Never use SSD for xdg-toplevel clients that don't support xdg-decoration. This means that GTK windows would always be client side decorated in river. This would be more strictly in conformance with the wayland protocol.
- Unset the xdg toplevel tiled state for floating views, keep it set for tiled views. Again, this is the "right" thing to do according to the protocol and will fix the issue mentioned with mpv above.
I have been thinking about this a bit.
I don't really like 2. Currently the only difference between tiled and floating views is that the former is automatically arranged and the latter manually while also being on top. Other than that they are pretty much identical and I think this is the Right Thing™ for river to do. I personally don't want a views appearance or behaviour to change when I switch it from tiling to floating or vice versa and this change could mean that.
1 sounds a bit better. It might upset the SSD purists, but AFAIK GTK4 supports the correct protocol and maybe eventually GTK3 will as well, so I don't think that is an issue. If we choose to go this route, we can potentially completely get rid of the xdg-toplevel tiled state. A client using xdg-decoration and being in SSD mode is very unlikely to change its rendering based on that, so for these views it does not matter. For CSD views setting the tiled state even if the view is non-floating is also not necessarily correct, since there are no guarantees that the layout arranges them in a way that tiles them against something. In fact, for every layout with gaps/padding, the tiled state is already incorrect.
Or as an alternative, acknowledge that the protocols don't work very well for our use case and accept the current slightly broken state.
Another alternative: Go with the window management protocol and let window managers set tiled state and CSD/SSD state independently. Then we could keep the decision making and therefore this problem out of the server.
So what the decision for this, I saw I have a branch laying here since some weeks with a fix for 2, fixing mpv
