[PATCH RFC] xdg-shell: Add tiled states

[Olivier Fourdan]

Hi

On 2 June 2016 at 15:51, Drew DeVault <sir at cmpwn.com> wrote:
> This protocol seems to be barking up the wrong tree. This protocol only
> serves traditional floating WMs for whom tiling only goes as far as
> filling 50% of the screen with a window (as mentioned by others) and
> isn't very flexible beyond that.

Can you elaborate, what makes xdg-shell not flexible enough that it
would require an additional protocol?

>  I think this should be addressed in two alternative ways:
>
> 1. Surfaces always respect the geometry they're given by the compositor.
> I'm looking at you, gnome-calculator.

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

> 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.

> 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?

How does that relate to the way the WM tiles its windows? Tiling
vertically is just one form of tiling, if you can define tiling in the
existing protocol, then you can define the 50% vertical or horizontal
tiling that some lesser tiling WM do... (and before anyone takes
offence, I don't mean lesser in a bad way here, I just use "lesser" as
opposed to true tiling WMs)

> 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.

Cheers,
Olivier