[RFC] xdg-shell: Add tiled states

Submitted by Olivier Fourdan on June 1, 2016, 9:18 a.m.

Details

Message ID 1464772739-1579-2-git-send-email-ofourdan@redhat.com
State RFC
Headers show
Series "xdg-shell: Add tiled states" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Olivier Fourdan June 1, 2016, 9:18 a.m.
When tiled, clients must obey the window geometry specified in the
configure event and can choose to hide some of their decorations.

Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27 +++++++++++++++++++++++++++
 1 file changed, 27 insertions(+)

Patch hide | download patch | download mbox

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index ce57153..550a0e5 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -343,6 +343,33 @@ 
 	  active. Do not assume this means that the window actually has
 	  keyboard or pointer focus.
 	</description>
+      <entry name="tiled_on_top" value="5" summary="the surface is tiled on its top edge">
+	<description summary="the surface is tiled on its top side">
+	  The top side of the surface is tiled, either to another surface
+	  or a monitor edge. The window geometry specified in the configure
+	  event must be obeyed by the client.
+	</description>
+      </entry>
+      <entry name="tiled_on_bottom" value="6" summary="the surface is tiled on its bottom edge">
+	<description summary="the surface is tiled on its bottom side">
+	  The bottom side of the surface is tiled, either to another surface
+	  or a monitor edge. The window geometry specified in the configure
+	  event must be obeyed by the client.
+	</description>
+      </entry>
+      <entry name="tiled_on_left" value="7" summary="the surface is tiled on its left edge">
+	<description summary="the surface is tiled on its left side">
+	  The left side of the surface is tiled, either to another surface
+	  or a monitor edge. The window geometry specified in the configure
+	  event must be obeyed by the client.
+	</description>
+      </entry>
+      <entry name="tiled_on_right" value="8" summary="the surface is tiled on its right edge">
+	<description summary="the surface is tiled on its right side">
+	  TThe right side of the surface is tiled, either to another surface
+	  or a monitor edge. The window geometry specified in the configure
+	  event must be obeyed by the client.
+	</description>
       </entry>
     </enum>
 

Comments

Hi,

On Wed, Jun 1, 2016 at 5:19 AM Olivier Fourdan <ofourdan@redhat.com> wrote:

> When tiled, clients must obey the window geometry specified in the
> configure event and can choose to hide some of their decorations.
>
> Signed-off-by: Olivier Fourdan <ofourdan@redhat.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 27
> +++++++++++++++++++++++++++
>  1 file changed, 27 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index ce57153..550a0e5 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -343,6 +343,33 @@
>           active. Do not assume this means that the window actually has
>           keyboard or pointer focus.
>         </description>
> +      <entry name="tiled_on_top" value="5" summary="the surface is tiled
> on its top edge">
> +       <description summary="the surface is tiled on its top side">
> +         The top side of the surface is tiled, either to another surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_bottom" value="6" summary="the surface is
> tiled on its bottom edge">
> +       <description summary="the surface is tiled on its bottom side">
> +         The bottom side of the surface is tiled, either to another
> surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_left" value="7" summary="the surface is tiled
> on its left edge">
> +       <description summary="the surface is tiled on its left side">
> +         The left side of the surface is tiled, either to another surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
> +      </entry>
> +      <entry name="tiled_on_right" value="8" summary="the surface is
> tiled on its right edge">
> +       <description summary="the surface is tiled on its right side">
> +         TThe right side of the surface is tiled, either to another
> surface
> +         or a monitor edge. The window geometry specified in the configure
> +         event must be obeyed by the client.
> +       </description>
>        </entry>
>      </enum>
>
> --
> 2.7.4
>
>
>
I've read the ticket linked in the other mail, but your use of "tiled" here
is confusing to me since you (and the ticket) appear to be conflating two
separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
which organizes windows into a tiled grid formation; this is in opposition
to "stacking".

The ticket you linked seems to be primarily about positioning windows to
take up 50% of screen geometry, (e.g., left half of screen, top half of
screen, ...). This seems a lot more like a maximize state to me since it's
based on screen geometry. In X11 there's NETWM hints for
vertical/horizontal maximize: EFL uses these to handle partial
maximizations, and in Wayland we simply use the normal MAXIMIZE window
state since directionality is irrelevant. I think MAXIMIZE fully covers
this case and there is no need for any further protocol to inform the
client.

In the case of the real "tiled" state, (i.e., a tiling layout policy), I
think this is something which should be a single draw state. There's no
need to inform a client about its surface's relative position (e.g., any of
your proposed directional tiled values) since the result is the same in
every case--the client must obey configured geometry.

The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
indicates to a client that a surface is taking up the entire screen's
geometry on at least one axis and thus it may choose to draw UI elements
differently (e.g., showing/hiding extra toolbars along the larger axis). A
TILED state simply informs the client that it must obey sizing policies and
draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
implicitly "tiled" by being maximized), but a tiled surface can toggle
MAXIMIZE.
Hi Mike,

----- Original Message -----
> I've read the ticket linked in the other mail, but your use of "tiled" here
> is confusing to me since you (and the ticket) appear to be conflating two
> separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
> which organizes windows into a tiled grid formation; this is in opposition
> to "stacking".

Sure, I appreciate that.
 
> The ticket you linked seems to be primarily about positioning windows to
> take up 50% of screen geometry, (e.g., left half of screen, top half of
> screen, ...). This seems a lot more like a maximize state to me since it's
> based on screen geometry. In X11 there's NETWM hints for
> vertical/horizontal maximize: EFL uses these to handle partial
> maximizations, and in Wayland we simply use the normal MAXIMIZE window
> state since directionality is irrelevant.

This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.

> I think MAXIMIZE fully covers
> this case and there is no need for any further protocol to inform the
> client.

I reckon using partial maximization from EWMH to achieve basic tiling in gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:

https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244

And it doesn't even take into account horizontal tiling, https://bugzilla.gnome.org/show_bug.cgi?id=742525

I'd rather not mix up maximization and tiling again, given the chance...

> In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> think this is something which should be a single draw state. There's no
> need to inform a client about its surface's relative position (e.g., any of
> your proposed directional tiled values) since the result is the same in
> every case--the client must obey configured geometry.

The client may chose to draw the border on the surface edged tiled differently, to achieve seamless borders between tiled windows for example, while keeping the other edges (not tiled) unchanged, that was the idea behind the use of the edge values.
 
> The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
> indicates to a client that a surface is taking up the entire screen's
> geometry on at least one axis and thus it may choose to draw UI elements
> differently (e.g., showing/hiding extra toolbars along the larger axis). A
> TILED state simply informs the client that it must obey sizing policies and
> draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> implicitly "tiled" by being maximized), but a tiled surface can toggle
> MAXIMIZE.

I see where you're coming from, if we consider a single "tiled" state then it's similar in essence to the maximized state with a different geometry, so we could get away with a "tiled" draw state instead that clients would use to distinguish from the real "maximize" state when drawing their decorations (including the "maximize" button in the title bar which can differ when maximized or not).

Granted, I am not a tiling window manager aficionado myself, so it would be great if those who design tiling window managers could chime in as well and express their needs wrt. tiling.

Cheers,
Olivier
On Wed, Jun 1, 2016 at 10:42 AM Olivier Fourdan <ofourdan@redhat.com> wrote:

> Hi Mike,
>
> ----- Original Message -----
> > I've read the ticket linked in the other mail, but your use of "tiled"
> here
> > is confusing to me since you (and the ticket) appear to be conflating two
> > separate-but-unrelated meanings.  "Tiled" is a type of window layout
> policy
> > which organizes windows into a tiled grid formation; this is in
> opposition
> > to "stacking".
>
> Sure, I appreciate that.
>
> > The ticket you linked seems to be primarily about positioning windows to
> > take up 50% of screen geometry, (e.g., left half of screen, top half of
> > screen, ...). This seems a lot more like a maximize state to me since
> it's
> > based on screen geometry. In X11 there's NETWM hints for
> > vertical/horizontal maximize: EFL uses these to handle partial
> > maximizations, and in Wayland we simply use the normal MAXIMIZE window
> > state since directionality is irrelevant.
>
> This is the current use of "tiling" in gnome-shell and gtk+, but we should
> not limit tiling to a single (very limited) implementation.
>

I'll ask you to clarify which "tiling" you're referring to in this case; I
don't believe that gtk's toolkit implementation of a single state for two
separate functionalities should dictate the protocol in this case.


>
> > I think MAXIMIZE fully covers
> > this case and there is no need for any further protocol to inform the
> > client.
>
> I reckon using partial maximization from EWMH to achieve basic tiling in
> gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
>
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
>
> And it doesn't even take into account horizontal tiling,
> https://bugzilla.gnome.org/show_bug.cgi?id=742525
>
> I'd rather not mix up maximization and tiling again, given the chance...
>

You're conflating different issues again, I think. On client-side, maximize
is typically only initiated using a window decoration button. Other forms
of maximize (e.g., partial maximizes) are compositor maximizes, and I think
this is a significant difference to note.
I imagine that you aren't advocating adding enough buttons to your
application/toolkit UI to enact all the maximize/tile states that you've
proposed, so this is purely a question of compositor policy vs client-side
internals. What you've cited in your case looks to just be an
implementation bug in your toolkit; Enlightenment/EFL have handled both
tiling layout policies and partial maximize states since before the E17
release, so that's sufficient proof for me that it's doable.


>
> > In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> > think this is something which should be a single draw state. There's no
> > need to inform a client about its surface's relative position (e.g., any
> of
> > your proposed directional tiled values) since the result is the same in
> > every case--the client must obey configured geometry.
>
> The client may chose to draw the border on the surface edged tiled
> differently, to achieve seamless borders between tiled windows for example,
> while keeping the other edges (not tiled) unchanged, that was the idea
> behind the use of the edge values.
>

I obviously don't have as much experience writing applications for your
desktop/toolkit UX standards, but it seems like having one side of a window
square and another side round is not going to look very good. Certainly
it's not something I plan on implementing in EFL at any point.


>
> > The difference from the MAXIMIZE state here is mostly conceptual:
> MAXIMIZE
> > indicates to a client that a surface is taking up the entire screen's
> > geometry on at least one axis and thus it may choose to draw UI elements
> > differently (e.g., showing/hiding extra toolbars along the larger axis).
> A
> > TILED state simply informs the client that it must obey sizing policies
> and
> > draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> > implicitly "tiled" by being maximized), but a tiled surface can toggle
> > MAXIMIZE.
>
> I see where you're coming from, if we consider a single "tiled" state then
> it's similar in essence to the maximized state with a different geometry,
> so we could get away with a "tiled" draw state instead that clients would
> use to distinguish from the real "maximize" state when drawing their
> decorations (including the "maximize" button in the title bar which can
> differ when maximized or not).
>
> Granted, I am not a tiling window manager aficionado myself, so it would
> be great if those who design tiling window managers could chime in as well
> and express their needs wrt. tiling.
>
> Cheers,
> Olivier
>
>
Enlightenment has a functioning tiling layout policy, so I've been chiming
in from that perspective as well.
On Wed, Jun 01, 2016 at 10:42:23AM -0400, Olivier Fourdan wrote:
> Hi Mike,
> 
> ----- Original Message -----
> > I've read the ticket linked in the other mail, but your use of "tiled" here
> > is confusing to me since you (and the ticket) appear to be conflating two
> > separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
> > which organizes windows into a tiled grid formation; this is in opposition
> > to "stacking".
> 
> Sure, I appreciate that.
>  
> > The ticket you linked seems to be primarily about positioning windows to
> > take up 50% of screen geometry, (e.g., left half of screen, top half of
> > screen, ...). This seems a lot more like a maximize state to me since it's
> > based on screen geometry. In X11 there's NETWM hints for
> > vertical/horizontal maximize: EFL uses these to handle partial
> > maximizations, and in Wayland we simply use the normal MAXIMIZE window
> > state since directionality is irrelevant.
> 
> This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.
> 
> > I think MAXIMIZE fully covers
> > this case and there is no need for any further protocol to inform the
> > client.
> 
> I reckon using partial maximization from EWMH to achieve basic tiling in gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
> 
> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
> 
> And it doesn't even take into account horizontal tiling, https://bugzilla.gnome.org/show_bug.cgi?id=742525
> 
> I'd rather not mix up maximization and tiling again, given the chance...
> 
> > In the case of the real "tiled" state, (i.e., a tiling layout policy), I
> > think this is something which should be a single draw state. There's no
> > need to inform a client about its surface's relative position (e.g., any of
> > your proposed directional tiled values) since the result is the same in
> > every case--the client must obey configured geometry.
> 
> The client may chose to draw the border on the surface edged tiled differently, to achieve seamless borders between tiled windows for example, while keeping the other edges (not tiled) unchanged, that was the idea behind the use of the edge values.
>  
> > The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
> > indicates to a client that a surface is taking up the entire screen's
> > geometry on at least one axis and thus it may choose to draw UI elements
> > differently (e.g., showing/hiding extra toolbars along the larger axis). A
> > TILED state simply informs the client that it must obey sizing policies and
> > draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
> > implicitly "tiled" by being maximized), but a tiled surface can toggle
> > MAXIMIZE.
> 
> I see where you're coming from, if we consider a single "tiled" state then it's similar in essence to the maximized state with a different geometry, so we could get away with a "tiled" draw state instead that clients would use to distinguish from the real "maximize" state when drawing their decorations (including the "maximize" button in the title bar which can differ when maximized or not).

I fail to see what makes tiling and maximized so significantly different
that one would require a predictable negotiation. This would just mean
that a tiling compositor can't properly tile surfaces that doesn't
support an optional draw state.

If the tiling compositor still would draw the surface tiled which didn't
support the tiled draw state, then I see no point what so ever having to
negotiate anything, since the end result for the compositor would be
100% the same.

So, what is the reason a tiled state an optional state that requires
negotiation, while maximized does not?


Jonas

> 
> Granted, I am not a tiling window manager aficionado myself, so it would be great if those who design tiling window managers could chime in as well and express their needs wrt. tiling.
> 
> Cheers,
> Olivier
> 
>  
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Hello Jonas,

The things I see for maximized vs. tilling:
 - tilling window does not need a unmaximize button, because they are
not maximized;
 - tilling window may want to switch maximized and draw the
corresponding button;
 - tilling window may not need close button to be drawn.

We will quickly end up to _NET_WM_ALLOWED_ACTIONS :)

Side note: I'm using my own hand written tilling window manager named page.

Best regards.

On 02/06/2016 03:01, Jonas Ådahl wrote:
> On Wed, Jun 01, 2016 at 10:42:23AM -0400, Olivier Fourdan wrote:
>> Hi Mike,
>>
>> ----- Original Message -----
>>> I've read the ticket linked in the other mail, but your use of "tiled" here
>>> is confusing to me since you (and the ticket) appear to be conflating two
>>> separate-but-unrelated meanings.  "Tiled" is a type of window layout policy
>>> which organizes windows into a tiled grid formation; this is in opposition
>>> to "stacking".
>>
>> Sure, I appreciate that.
>>  
>>> The ticket you linked seems to be primarily about positioning windows to
>>> take up 50% of screen geometry, (e.g., left half of screen, top half of
>>> screen, ...). This seems a lot more like a maximize state to me since it's
>>> based on screen geometry. In X11 there's NETWM hints for
>>> vertical/horizontal maximize: EFL uses these to handle partial
>>> maximizations, and in Wayland we simply use the normal MAXIMIZE window
>>> state since directionality is irrelevant.
>>
>> This is the current use of "tiling" in gnome-shell and gtk+, but we should not limit tiling to a single (very limited) implementation.
>>
>>> I think MAXIMIZE fully covers
>>> this case and there is no need for any further protocol to inform the
>>> client.
>>
>> I reckon using partial maximization from EWMH to achieve basic tiling in gnome-shell/gtk+ was a hack, it leads to all sort of workarounds in gtk+:
>>
>> https://git.gnome.org/browse/gtk+/tree/gdk/x11/gdkdisplay-x11.c#n244
>>
>> And it doesn't even take into account horizontal tiling, https://bugzilla.gnome.org/show_bug.cgi?id=742525
>>
>> I'd rather not mix up maximization and tiling again, given the chance...
>>
>>> In the case of the real "tiled" state, (i.e., a tiling layout policy), I
>>> think this is something which should be a single draw state. There's no
>>> need to inform a client about its surface's relative position (e.g., any of
>>> your proposed directional tiled values) since the result is the same in
>>> every case--the client must obey configured geometry.
>>
>> The client may chose to draw the border on the surface edged tiled differently, to achieve seamless borders between tiled windows for example, while keeping the other edges (not tiled) unchanged, that was the idea behind the use of the edge values.
>>  
>>> The difference from the MAXIMIZE state here is mostly conceptual: MAXIMIZE
>>> indicates to a client that a surface is taking up the entire screen's
>>> geometry on at least one axis and thus it may choose to draw UI elements
>>> differently (e.g., showing/hiding extra toolbars along the larger axis). A
>>> TILED state simply informs the client that it must obey sizing policies and
>>> draw rectangular borders. A MAXIMIZED surface cannot be tiled (since it's
>>> implicitly "tiled" by being maximized), but a tiled surface can toggle
>>> MAXIMIZE.
>>
>> I see where you're coming from, if we consider a single "tiled" state then it's similar in essence to the maximized state with a different geometry, so we could get away with a "tiled" draw state instead that clients would use to distinguish from the real "maximize" state when drawing their decorations (including the "maximize" button in the title bar which can differ when maximized or not).
> 
> I fail to see what makes tiling and maximized so significantly different
> that one would require a predictable negotiation. This would just mean
> that a tiling compositor can't properly tile surfaces that doesn't
> support an optional draw state.
> 
> If the tiling compositor still would draw the surface tiled which didn't
> support the tiled draw state, then I see no point what so ever having to
> negotiate anything, since the end result for the compositor would be
> 100% the same.
> 
> So, what is the reason a tiled state an optional state that requires
> negotiation, while maximized does not?
> 
> 
> Jonas
> 
>>
>> Granted, I am not a tiling window manager aficionado myself, so it would be great if those who design tiling window managers could chime in as well and express their needs wrt. tiling.
>>
>> Cheers,
>> Olivier
>>
>>  
>> _______________________________________________
>> wayland-devel mailing list
>> wayland-devel@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
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. 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.
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.

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.

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

--
Drew DeVault
Hi

On 2 June 2016 at 15:51, Drew DeVault <sir@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
> 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
Hi

On 2 June 2016 at 16:44, Drew DeVault <sir@cmpwn.com> wrote:
> [...]
>>
>> 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.

Oh I see, there is a misunderstanding here, "edge" in my proposal does
not denote the monitor's edges but the window's edges.

So in your example, all 3 windows would be tiled on all 4 edges,
including the one in the middle as it's tiled against the montoir
edged at its top and bottom, and to the other windows on its right and
left edges.

This is why the description in my patch for each state reads "The xxxx
side of the surface is tiled, either to another surface or a monitor
edge".

In the light of this, I suspect Mike might also have misunderstood my
proposal,I did not understand why people kept referring to the
gnome-shell implementation of tiling...

Cheers,
Olivier
On 2016-06-02  5:00 PM, Olivier Fourdan wrote:
> Oh I see, there is a misunderstanding here, "edge" in my proposal does
> not denote the monitor's edges but the window's edges.
> 
> So in your example, all 3 windows would be tiled on all 4 edges,
> including the one in the middle as it's tiled against the montoir
> edged at its top and bottom, and to the other windows on its right and
> left edges.
> 
> This is why the description in my patch for each state reads "The xxxx
> side of the surface is tiled, either to another surface or a monitor
> edge".
> 
> In the light of this, I suspect Mike might also have misunderstood my
> proposal,I did not understand why people kept referring to the
> gnome-shell implementation of tiling...

Aha, I see. I have no real objections to your protocol then, though of
course in Sway I expect it'll just say all four edges are tiled at all
times.

I still maintain that the other issues I brought up should be addressed
to support tiling window management, such as negotiating for
client/server side decorations and support for various xdg-shell
features like maximize/minimize.

--
Drew DeVault
Hello,

For reference this discussion was split from [1]. Note also I did this
comment in the thread [2].

And I reiterate that we are making :
 -  _NET_SUPPORTED [3],
 -  _NET_WM_ALLOWED_ACTIONS [4]
 - and _NET_WM_STATE [5].

So why not drafting from the existing and improve it ?

[1]
https://lists.freedesktop.org/archives/wayland-devel/2016-May/029106.html
[2]
https://lists.freedesktop.org/archives/wayland-devel/2016-May/029161.html
[3]
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472725888
[4]
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792
[5]
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472615568

Best regards.

On 02/06/2016 17:03, Drew DeVault wrote:
> On 2016-06-02  5:00 PM, Olivier Fourdan wrote:
>> Oh I see, there is a misunderstanding here, "edge" in my proposal does
>> not denote the monitor's edges but the window's edges.
>>
>> So in your example, all 3 windows would be tiled on all 4 edges,
>> including the one in the middle as it's tiled against the montoir
>> edged at its top and bottom, and to the other windows on its right and
>> left edges.
>>
>> This is why the description in my patch for each state reads "The xxxx
>> side of the surface is tiled, either to another surface or a monitor
>> edge".
>>
>> In the light of this, I suspect Mike might also have misunderstood my
>> proposal,I did not understand why people kept referring to the
>> gnome-shell implementation of tiling...
> 
> Aha, I see. I have no real objections to your protocol then, though of
> course in Sway I expect it'll just say all four edges are tiled at all
> times.
> 
> I still maintain that the other issues I brought up should be addressed
> to support tiling window management, such as negotiating for
> client/server side decorations and support for various xdg-shell
> features like maximize/minimize.
> 
> --
> Drew DeVault
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>