[PATCH RFC] xdg-shell: Add tiled states

[Drew DeVault]

> 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