xdg-shell: add enums for tiled window state to toplevel configure

Submitted by Mike Blumenkrantz on March 20, 2018, 1:52 p.m.

Details

Message ID 20180320135202.5782-1-zmike@osg.samsung.com
State New
Headers show
Series "xdg-shell: add enums for tiled window state to toplevel configure" ( rev: 1 ) in Wayland

Not browsing as part of any series.

Commit Message

Mike Blumenkrantz March 20, 2018, 1:52 p.m.
this adds implementation from a related discussion long ago in which
it was decided that it would be useful for clients to know if/where their
windows were tiled so that various behaviors and visuals could be modified
to improve UX

a window which is e.g., tiled on the right side of the screen would set the
right|top|bottom tiled states in configure

Signed-off-by: Mike Blumenkrantz <zmike@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 34 +++++++++++++++++++++++++++++-----
 1 file changed, 29 insertions(+), 5 deletions(-)

Patch hide | download patch | download mbox

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..a87527c 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -29,7 +29,7 @@ 
     DEALINGS IN THE SOFTWARE.
   </copyright>
 
-  <interface name="xdg_wm_base" version="1">
+  <interface name="xdg_wm_base" version="2">
     <description summary="create desktop-style surfaces">
       The xdg_wm_base interface is exposed as a global object enabling clients
       to turn their wl_surfaces into windows in a desktop environment. It
@@ -115,7 +115,7 @@ 
     </event>
   </interface>
 
-  <interface name="xdg_positioner" version="1">
+  <interface name="xdg_positioner" version="2">
     <description summary="child surface positioner">
       The xdg_positioner provides a collection of rules for the placement of a
       child surface relative to a parent surface. Rules can be defined to ensure
@@ -359,7 +359,7 @@ 
     </request>
   </interface>
 
-  <interface name="xdg_surface" version="1">
+  <interface name="xdg_surface" version="2">
     <description summary="desktop user interface surface base interface">
       An interface that may be implemented by a wl_surface, for
       implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@ 
     </event>
   </interface>
 
-  <interface name="xdg_toplevel" version="1">
+  <interface name="xdg_toplevel" version="2">
     <description summary="toplevel surface">
       This interface defines an xdg_surface role which allows a surface to,
       among other things, set window-like properties such as maximize,
@@ -750,6 +750,30 @@ 
 	  keyboard or pointer focus.
 	</description>
       </entry>
+      <entry name="tiled_left" value="5" summary="the surface is now tiled">
+	<description summary="the surface is now tiled">
+	  The window is currently in a tiled layout and the left edge is considered to be
+	  adjacent to another part of the tiling grid.
+	</description>
+      </entry>
+      <entry name="tiled_right" value="6" summary="the surface is now tiled">
+	<description summary="the surface is now tiled">
+	  The window is currently in a tiled layout and the right edge is considered to be
+	  adjacent to another part of the tiling grid.
+	</description>
+      </entry>
+      <entry name="tiled_top" value="7" summary="the surface is now tiled">
+	<description summary="the surface is now tiled">
+	  The window is currently in a tiled layout and the top edge is considered to be
+	  adjacent to another part of the tiling grid.
+	</description>
+      </entry>
+      <entry name="tiled_bottom" value="8" summary="the surface is now tiled">
+	<description summary="the surface is now tiled">
+	  The window is currently in a tiled layout and the bottom edge is considered to be
+	  adjacent to another part of the tiling grid.
+	</description>
+      </entry>
     </enum>
 
     <request name="set_max_size">
@@ -989,7 +1013,7 @@ 
     </event>
   </interface>
 
-  <interface name="xdg_popup" version="1">
+  <interface name="xdg_popup" version="2">
     <description summary="short-lived, popup surfaces for menus">
       A popup surface is a short-lived, temporary surface. It can be used to
       implement for example menus, popovers, tooltips and other similar user

Comments

On Tue, 20 Mar 2018 at 09:52:02 -0400, Mike Blumenkrantz wrote:
> this adds implementation from a related discussion long ago in which
> it was decided that it would be useful for clients to know if/where their
> windows were tiled so that various behaviors and visuals could be modified
> to improve UX
> 
> a window which is e.g., tiled on the right side of the screen would set the
> right|top|bottom tiled states in configure

Are these for the same purpose as the tiled states in the (currently private)
protocol between GTK+ and Mutter/GNOME Shell?

This has separate per-edge flags for:

- Tiling: each edge is tiled (aligned to some other object) or not, so
  that windows and client-side decorations can make UI choices like
  "draw shadows on each edge that is not tiled" or "draw square corners
  at each corner involving a tiled edge, and rounded corners where
  neither edge is tiled"

- Resizability: each edge is resizable or not, so that client-side
  decorations can show or not show resize handles as appropriate (in
  GNOME Shell you can tile two windows and then drag their shared
  border to adjust the split, and I suspect that the Wayland equivalents
  of X11 tiling window managers would want this too)

https://bugzilla.gnome.org/show_bug.cgi?id=751857
https://gitlab.gnome.org/GNOME/mutter/blob/master/src/wayland/protocol/gtk-shell.xml

Regards,
    smcv
On Tue, Mar 20, 2018 at 10:15 AM Simon McVittie <smcv@collabora.com> wrote:

> On Tue, 20 Mar 2018 at 09:52:02 -0400, Mike Blumenkrantz wrote:
> > this adds implementation from a related discussion long ago in which
> > it was decided that it would be useful for clients to know if/where their
> > windows were tiled so that various behaviors and visuals could be
> modified
> > to improve UX
> >
> > a window which is e.g., tiled on the right side of the screen would set
> the
> > right|top|bottom tiled states in configure
>
> Are these for the same purpose as the tiled states in the (currently
> private)
> protocol between GTK+ and Mutter/GNOME Shell?
>
> This has separate per-edge flags for:
>
> - Tiling: each edge is tiled (aligned to some other object) or not, so
>   that windows and client-side decorations can make UI choices like
>   "draw shadows on each edge that is not tiled" or "draw square corners
>   at each corner involving a tiled edge, and rounded corners where
>   neither edge is tiled"
>
> - Resizability: each edge is resizable or not, so that client-side
>   decorations can show or not show resize handles as appropriate (in
>   GNOME Shell you can tile two windows and then drag their shared
>   border to adjust the split, and I suspect that the Wayland equivalents
>   of X11 tiling window managers would want this too)
>
> https://bugzilla.gnome.org/show_bug.cgi?id=751857
>
> https://gitlab.gnome.org/GNOME/mutter/blob/master/src/wayland/protocol/gtk-shell.xml
>
> Regards,
>     smcv
> _______________________________________________
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


They could be used for those purposes, yes.
On 2018-03-20  9:52 AM, Mike Blumenkrantz wrote:
> this adds implementation from a related discussion long ago in which
> it was decided that it would be useful for clients to know if/where their
> windows were tiled so that various behaviors and visuals could be modified
> to improve UX
> 
> a window which is e.g., tiled on the right side of the screen would set the
> right|top|bottom tiled states in configure

+1