> Can you elaborate, what makes xdg-shell not flexible enough that it > would require an additional protocol?
I don't think it requires another protocol. I think it requires less protocols. I want to take a step back and address this at a higher level, I think your solution is too specific. > That should be addressed by the min/max in xdg-shell v6 > > https://bugzilla.gnome.org/show_bug.cgi?id=764413 > https://cgit.freedesktop.org/wayland/wayland-protocols/commit/?h=wip/xdg-shell-unstable-v6&id=8ad8f92 Cool. Not exactly what I want to see as a solution here but good enough for me to work around the problem in Sway. > > 2. A protocol that communicates window management capabilities from the > > compositor to the surfaces like whether or not maximizing or minimizing > > surfaces makes sense in this compositor. > > That sounds like a specific protocol for specific compositors to me, > that does not necessarily belong to xdg-shell as I understand it. OTOH it seems very on-topic for the xdg-shell protocol. It allows the compositor to communicate a specific subset of xdg-shell capabilities that make sense for that compositor rather than assuming that xdg-shell is a one-size-fits-all solution and letting breakage occur when that's not the case. A client drawing a minimize button on its CSD that doesn't work because the compositor doesn't have any concept of minimizing windows is a less than ideal situation. > > Then if you need an extra protocol for your floating WM's 50% stuff so > > that the windows can adjust their window decorations or whatnot then > > that should be seperate. > > Why a separate protocol for that sole purpose, why not using Mike's > "draw state" proposal? Your protocol suggests that the only ways a window can be tiled is against an edge. This is not the case. In most tiling window managers the following situation could happen: x x x Where each x is a window, equally sized. How does your protocol accomodate for the middle window? The protocol is too specific and not flexible enough. The problems it tries to solve should be solved at a higher level and if you need to communicate orientation near a screen edge to a client for your specific compositor's use-case then a special protocol would be the right call IMO. > > I also think with respect to window decorations that there needs to be a > > protocol that communicates a preference between the compositor and the > > clients. The compositor should be able to say "please don't draw window > > decorations" and the client should either say "okay" or "but I have > > meaningful UI components in my window decorations so I'm gonna draw them > > anyway, and I'm letting you know that so you don't do it for me". > > I reckon having a compositor/client negotiation as to which component > is handled in CSD or SSD would put some additional burden not only on > the toolkit but on applications designers as well. Correct. -- Drew DeVault _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
