Re: wayland-protocols scope and governance

[Mike Blumenkrantz]

Hi,

I've been following along on this thread, and I really appreciate that
you've reached out to me.

The current document seems reasonable to me. It will be a positive for the
ecosystem to have a clearly-defined method of proposing and stabilizing new
protocols for adoption.

I'm not quite as active in the Wayland space as I have been historically,
but EFL/Enlightenment does have interest in joining this community and I'm
still probably the best point of contact at this time.


Regards,
Mike

PS. The email address you used for Derek is no longer active (it hasn't
been for years) and you should likely check with him on IRC for a more
up-to-date address and/or interest.

On Wed, Oct 16, 2019 at 5:17 AM Simon Ser  wrote:

> [Cc'ing more people]
>
> > > Points of contact I had in mind:
> > >
> > > - KWin: Roman Gilg 
> > > - Mutter: Jonas Ådahl 
> > > - Weston: Pekka Paalanen ,
> > >   Daniel Stone 
> > > - wlroots: Drew DeVault , Simon Ser <
> cont...@emersion.fr>
> > >
> > > I think it would make sense to include this initial list in a MEMBERS
> > > file in the upcoming wayland-protocols patch series that adds this
> > > governance document.
> > >
> > > Thoughts?
> >
> > Sounds good to me!
> >
> > Prodding toolkit projects for people would be good, and also
> > Enlightenment.
>
> Hi all,
>
> We've been discussing for a while about wayland-protocols governance. You
> can
> find the latest proposal at [1].
>
> We're discussing about the initial list of members. Would Enlightenment,
> Qt and
> GTK be interested in being initial members as well?
>
> Feedback is welcome. Thanks,
>
> [1]:
> https://lists.freedesktop.org/archives/wayland-devel/2019-October/040919.html
>
> Simon
>
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: wayland-protocols scope and governance

[Mike Blumenkrantz]

Hello,

On Thu, Feb 21, 2019 at 10:47 AM Daniel Stone  wrote:

>
> One of Weston's goals is to be a reference compositor. As an active
> implementation, it serves as a useful neutral ground for the rest of
> the ecosystem: we try to be exhaustively correct in what we do
> implement, and gets used as a litmus test for clients and compositors
> both to compare their behaviour against (who's interpreted the spec
> incorrectly?). We take that responsibility pretty seriously, which
> places a ceiling on the rate of change as well as the breadth of
> functionality we can implement.
>
> There used to be a rule (observed in all but extremis) that any common
> protocol had to have a Weston implementation, as the closest analogue
> we had to a conformance test suite. That was abandoned long ago, since
> there are some protocols for which it wasn't practical to do so. That
> was the point beyond which we moved from Weston being _the_ reference
> compositor for the entire ecosystem, to just being a useful resource.
> (I get that Weston's README still says 'Weston is the reference
> implementation of a Wayland compositor' as literally its first words.
> I'd personally be OK with changing that.)
>
> Weston is also useful as a demonstration vehicle for new low-level
> graphics functionality, particularly for EGL and KMS features. We were
> the first to do overlay planes, full damage tracking (and now
> per-plane KMS damage tracking), dmabuf, buffer modifiers, explicit
> fencing, atomic modesetting, same-CRTC clone mode (AFAIK),
> aspect-ratio modes, and so on. I'm pretty happy with how that's going,
> even if we do still have some feature gaps.
>
>
Speaking on an entirely personal level (i.e., unrelated to any project or
employer) and as someone who has spent an amount of time writing both
compositors and clients using Wayland protocols--and also writing those
protocols, I found this to be very accurate. My ability to successfully
implement protocols in compositors and clients has benefited tremendously
over the years from the existence of Weston and its clients, even despite
their noted shortcomings. I'll also go a step further and challenge anyone
who has done similar work to deny having similarly benefited from Weston.

If anything, I think devoting more time and energy to improving Weston and
underlying layers would only serve to help the Wayland-using community.
Better documentation and better reference code lowers barriers to entry and
improves the ecosystem: this is something I know all too well from some of
the projects that I've worked on.


Regards,
Mike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Mike Blumenkrantz]

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 <zm...@osg.samsung.com>
Reviewed-by: Jonas Ådahl <jad...@gmail.com>

Changes since v2: simplified docs
Changes since v1: added since=2 to enum members
---
 stable/xdg-shell/xdg-shell.xml | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..c4dedd0 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -29,7 +29,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@
 
   
 
-  
+  
 
   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.

   
+  
+   
+ The window is currently in a tiled layout and the left edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the right edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the top edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the bottom edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
 
 
 
@@ -989,7 +1013,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Mike Blumenkrantz]

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 <zm...@osg.samsung.com>

Changes since v1: added since=2 to enum members
---
 stable/xdg-shell/xdg-shell.xml | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index d524ea9..629b983 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -29,7 +29,7 @@
 DEALINGS IN THE SOFTWARE.
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@
 
   
 
-  
+  
 
   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.

   
+  
+   
+ The window is currently in a tiled layout and the left edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the right edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the top edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the bottom edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
 
 
 
@@ -989,7 +1013,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add enums for tiled window state to toplevel configure

[Mike Blumenkrantz]

On Tue, Mar 20, 2018 at 10:15 AM Simon McVittie <s...@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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Mike Blumenkrantz]

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 <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 34 +-
 1 file changed, 29 insertions(+), 5 deletions(-)

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.
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   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 @@
 
   
 
-  
+  
 
   An interface that may be implemented by a wl_surface, for
   implementations that provide a desktop-style user interface.
@@ -528,7 +528,7 @@
 
   
 
-  
+  
 
   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.

   
+  
+   
+ The window is currently in a tiled layout and the left edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the right edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the top edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
+  
+   
+ The window is currently in a tiled layout and the bottom edge is 
considered to be
+ adjacent to another part of the tiling grid.
+   
+  
 
 
 
@@ -989,7 +1013,7 @@
 
   
 
-  
+  
 
   A popup surface is a short-lived, temporary surface. It can be used to
   implement for example menus, popovers, tooltips and other similar user
-- 
2.14.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protcols v3] unstable: add xdg-toplevel-decoration protocol

[Mike Blumenkrantz]

It seems to me that there is no harm in restating that clients are required
to implement CSD inside a protocol which permits adding a separate,
optional method of window decoration.

Note that it is not an assumption that clients/compositors "support both"
modes, it's a hard requirement that clients/compositors support CSD. If
there is some confusion about this due to other protocols not explicitly
stating that CSD is required then this can easily be remedied by adding
such clauses.

On Wed, Mar 14, 2018 at 3:20 PM Drew DeVault  wrote:

> On 2018-03-14  3:16 PM, Simon Ser wrote:
> > However, the situation we'd like to avoid is clients wanting decorations
> not
> > implementing CSD at all and relying on this protocol to show them via
> SSD. What
> > about rewording this sentence to:
>
> I understand where you're coming from, but this is not something to be
> avoided, rather it should be embraced.
> ___
> 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

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

[Mike Blumenkrantz]

Hi,

I agree with your point regarding a SSD-capable compositor not always
wanting them, and certainly I can see the usefulness for cases such as what
you've cited. However, in the example you provided, it's easy enough for an
application to determine what desktop it's running in and then determine
whether to use SSD--if the compositor implements and advertises this
protocol then it's ultimately a client decision whether to use it.

My issue is in the inconsistency of the protocol that has been proposed
here. This is a protocol for enabling SSD; there should be no need for
anything related to CSD, and I don't think there is a need for clients to
have any form of protocol request to toggle between CSD and SSD.

Based on your assertion that borderless mode would be achieved in this
protocol in the CSD mode, I would raise the counterpoint that in this case
the client should just destroy the zxdg_toplevel_decoration_v1 object
which, according to the destroy request, would revert to the surface using
CSD anyway, furthering my assessment that there is indeed no need for any
mention of CSD in the protocol requests.

This change allows for everything except the destroy request to be removed
from zxdg_toplevel_decoration_v1, greatly simplifying the protocol as well
as implementations of it. The case of the compositor "ignoring" the request
to create SSD also becomes moot as well, since all that would mean is the
compositor has chosen to use a borderless state at this time (e.g., tiling
layout) which is irrelevant to the client anyway.

This aside, there's some other items of note here, such as the lack of
precision related to when the change in decoration management state takes
effect: most likely it should be applied on the next surface commit? I
think this should be specified in the zxdg_toplevel_decoration_v1 interface
description. Also, I would think that destroying the
zxdg_toplevel_decoration_manager_v1
object while any zxdg_toplevel_decoration_v1 objects exist should be a
client error, but this is similarly not specified anywhere.

Regards,
Mike

On Thu, Mar 1, 2018 at 1:18 PM Simon Ser <cont...@emersion.fr> wrote:

> Hi Mike,
>
> I don't think a compositor supporting the protocol means that it always
> wants SSDs. For instance, I can imagine a DE like GNOME supporting it:
> - Allowing clients that prefer SSDs to use SSDs, so that toolkits like
> GLFW or winit and apps like mpv don't have to draw decorations that'll look
> alien and don't respect the user's preferences
> - But still preferring CSDs, so that GTK+ apps can use them
>
> Also, the CSD mode allows the client to do not draw decorations at all.
>
> Regards,
>
> On March 1, 2018 7:01 PM, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
> > Hi,
> >
> > This patch is certainly an improvement upon the previous protocol draft
> which I reviewed, but it still does not address the most significant issue
> that I pointed out, which is that it both is too complex and lacks
> features. Why is there any "mode" when this is a protocol for enabling
> server-side decorations? By using the protocol in a server or client, you
> are enabling server-side decoration; why would there be any mention of
> client-side at all? If the compositor, for whatever reason, decides to do a
> runtime disable of SSD then it can simply destroy the global.
> >
> > Please see again my mail on this topic from the previous thread:
> https://lists.freedesktop.org/archives/wayland-devel/2018-January/036495.html
> >
> > Regards,
> >
> > Mike
> >
> > On Sun, Feb 18, 2018 at 3:01 PM Simon Ser <cont...@emersion.fr\> wrote:
> >
> > > This adds a new protocol to negotiate server- and client-side
> rendering of
> > >
> > > window decorations for xdg-toplevels.
> > >
> > > \-\-\-
> > >
> > > This is inspired by a protocol from KDE\[0\] which has been
> implemented in KDE
> > >
> > > and Sway and was submitted for consideration in 2017\[1\]. This patch
> provides an
> > >
> > > updated protocol with those concerns taken into account.
> > >
> > > This was iterated on privately between representatives of Sway and
> wlroots
> > >
> > > (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan
> Griffiths).
> > >
> > > A proof-of-concept of a client and server implementation is available
> at \[2\].
> > >
> > > \[0\]
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> > >
> > > \[1\]
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> > >
> > > \[2\] https://github.com/swaywm/wlroots/pull/638
> > >

Re: [PATCH wayland-protocols] unstable: add xdg-toplevel-decoration protocol

[Mike Blumenkrantz]

Hi,

This patch is certainly an improvement upon the previous protocol draft
which I reviewed, but it still does not address the most significant issue
that I pointed out, which is that it both is too complex and lacks
features. Why is there any "mode" when this is a protocol for enabling
server-side decorations? By using the protocol in a server or client, you
are enabling server-side decoration; why would there be any mention of
client-side at all? If the compositor, for whatever reason, decides to do a
runtime disable of SSD then it can simply destroy the global.

Please see again my mail on this topic from the previous thread:
https://lists.freedesktop.org/archives/wayland-devel/2018-January/036495.html

Regards,
Mike

On Sun, Feb 18, 2018 at 3:01 PM Simon Ser  wrote:

> This adds a new protocol to negotiate server- and client-side rendering of
> window decorations for xdg-toplevels.
> ---
> This is inspired by a protocol from KDE[0] which has been implemented in
> KDE
> and Sway and was submitted for consideration in 2017[1]. This patch
> provides an
> updated protocol with those concerns taken into account.
>
> This was iterated on privately between representatives of Sway and wlroots
> (Simon Ser and Drew DeVault), KDE (David Edmundson), and Mir (Alan
> Griffiths).
>
> A proof-of-concept of a client and server implementation is available at
> [2].
>
> [0]
> https://github.com/KDE/kwayland/blob/master/src/client/protocols/server-decoration.xml
> [1]
> https://lists.freedesktop.org/archives/wayland-devel/2017-October/035564.html
> [2] https://github.com/swaywm/wlroots/pull/638
>
>  Makefile.am|   1 +
>  unstable/xdg-toplevel-decoration/README|   4 +
>  .../xdg-toplevel-decoration-unstable-v1.xml| 127
> +
>  3 files changed, 132 insertions(+)
>  create mode 100644 unstable/xdg-toplevel-decoration/README
>  create mode 100644
> unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 4b9a901..07744e9 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -17,6 +17,7 @@ unstable_protocols =
>   \
>
> unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml
> \
> unstable/xdg-output/xdg-output-unstable-v1.xml
>   \
> unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
> +
>  unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
>   \
> $(NULL)
>
>  stable_protocols =
>  \
> diff --git a/unstable/xdg-toplevel-decoration/README
> b/unstable/xdg-toplevel-decoration/README
> new file mode 100644
> index 000..e927110
> --- /dev/null
> +++ b/unstable/xdg-toplevel-decoration/README
> @@ -0,0 +1,4 @@
> +xdg_toplevel_decoration protocol
> +
> +Maintainers:
> +Simon Ser 
> diff --git
> a/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> new file mode 100644
> index 000..acc1ed2
> --- /dev/null
> +++
> b/unstable/xdg-toplevel-decoration/xdg-toplevel-decoration-unstable-v1.xml
> @@ -0,0 +1,127 @@
> +
> +
> +  
> +Copyright © 2018 Simon Ser
> +
> +Permission is hereby granted, free of charge, to any person obtaining
> a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without
> limitation
> +the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the
> next
> +paragraph) shall be included in all copies or substantial portions of
> the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  This interface permits choosing between client-side and server-side
> +  window decorations for a toplevel surface.
> +
> +  A window decoration is a user interface component used to move,
> resize and
> +  change a window's state. It can be managed either by the client
> (part of
> +  the surface) or by the server.
> +
> +  By advertizing this interface the server anounces support for
> server-side
> +  window decorations.
> +
> +  Warning! 

Re: [PATCH 1/2] xdg-shell: move maximized state difnition together

[Mike Blumenkrantz]

With typos corrected:

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Tue, Feb 27, 2018 at 8:23 AM Silvan Jegen <s.je...@gmail.com> wrote:

> Hi
>
> One typo corrected below.
>
> On Tue, Feb 27, 2018 at 1:24 PM,  <w...@ongy.net> wrote:
> > From: Markus Ongyerth <w...@ongy.net>
> >
> > The xdg-shell documentation had part of the maximized state render
> > implications in the `set_maximized` request documentation, not the
> > actual state.
> > This moves the relevant lines into the state description.
> >
> > Signed-off-by: Markus Ongyerth <w...@ongy.net>
> > ---
> >  stable/xdg-shell/xdg-shell.xml | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> >
> > diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> > index d524ea9..0b21364 100644
> > --- a/stable/xdg-shell/xdg-shell.xml
> > +++ b/stable/xdg-shell/xdg-shell.xml
> > @@ -724,6 +724,9 @@
> > 
> >   The surface is maximized. The window geometry specified in the
> configure
> >   event must be obeyed by the client.
> > +
> > + The client should drawy without shadow or other
>
> s/drawy/draw/
>
>
> Cheers,
>
> Silvan
> ___
> 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

Re: [PATCH 2/2] xdg-shell: Make sure wording reflects expectations

[Mike Blumenkrantz]

Hi,

This seems like a reasonable direction for a change, though I would suggest
a slightly different approach. For all cases where it reads "the compositor
will respond by emitting", instead change to something like "if the
compositor decides to apply this state change then it will respond by
emitting". Such change clarifies the mechanism, as your patch intends,
while also preserving the requirement that the compositor emits a state and
geometry in a configure event in order to acknowledge requests for state
changes.

Regards,
Mike

On Tue, Feb 27, 2018 at 7:25 AM  wrote:

> From: Markus Ongyerth 
>
> The wording in xdg-shell `set_*` requests implies the compositor *will*
> react to requests.
> This would give clients the control over its state, while they should
> just be able to kindly ask for a state change.
> This makes sure the language reflects that and changes "will" to "may"
> in the relevant requests description.
>
> Signed-off-by: Markus Ongyerth 
> ---
>  stable/xdg-shell/xdg-shell.xml | 16 
>  1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/stable/xdg-shell/xdg-shell.xml
> b/stable/xdg-shell/xdg-shell.xml
> index 0b21364..c619634 100644
> --- a/stable/xdg-shell/xdg-shell.xml
> +++ b/stable/xdg-shell/xdg-shell.xml
> @@ -842,7 +842,7 @@
> Maximize the surface.
>
> After requesting that the surface should be maximized, the
> compositor
> -   will respond by emitting a configure event with the "maximized"
> state
> +   may respond by emitting a configure event with the "maximized"
> state
> and the required window geometry. The client should then update its
> content, drawing it in a maximized state. The client must also
> acknowledge the configure when committing the new content (see
> @@ -852,11 +852,11 @@
> surface, for example which output and what region of the screen
> should
> be used.
>
> -   If the surface was already maximized, the compositor will still
> emit
> +   If the surface was already maximized, the compositor will emit
> a configure event with the "maximized" state.
>
> If the surface is in a fullscreen state, this request has no direct
> -   effect. It will alter the state the surface is returned to when
> +   effect. It may alter the state the surface is returned to when
> unmaximized if not overridden by the compositor.
>
>  
> @@ -866,7 +866,7 @@
> Unmaximize the surface.
>
> After requesting that the surface should be unmaximized, the
> compositor
> -   will respond by emitting a configure event without the "maximized"
> +   may respond by emitting a configure event without the "maximized"
> state. If available, the compositor will include the window
> geometry
> dimensions the window had prior to being maximized in the configure
> event. The client must then update its content, drawing it in a
> @@ -878,11 +878,11 @@
> unmaximized; usually the position the surface had before
> maximizing, if
> applicable.
>
> -   If the surface was already not maximized, the compositor will still
> +   If the surface was already not maximized, the compositor will
> emit a configure event without the "maximized" state.
>
> If the surface is in a fullscreen state, this request has no direct
> -   effect. It will alter the state the surface is returned to when
> +   effect. It may alter the state the surface is returned to when
> unmaximized if not overridden by the compositor.
>
>  
> @@ -892,7 +892,7 @@
> Make the surface fullscreen.
>
> After requesting that the surface should be fullscreened, the
> -   compositor will respond by emitting a configure event with the
> +   compositor may respond by emitting a configure event with the
> "fullscreen" state and the fullscreen window geometry. The client
> must
> also acknowledge the configure when committing the new content (see
> ack_configure).
> @@ -921,7 +921,7 @@
> Make the surface no longer fullscreen.
>
> After requesting that the surface should be unfullscreened, the
> -   compositor will respond by emitting a configure event without the
> +   compositor may respond by emitting a configure event without the
> "fullscreen" state.
>
> Making a surface unfullscreen sets states for the surface based on
> the following:
> --
> 2.16.2
>
> ___
> 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

[PATCH] unstable: add xdg-session-management protocol

[Mike Blumenkrantz]

for a variety of cases it's desirable to have a method for negotiating
the restoration of previously-used states for a client's windows. this
helps for e.g., a compositor/client crashing (definitely not due to
bugs) or a backgrounded client deciding to temporarily destroy its
surfaces in order to conserve resources

this protocol adds a method for managing such negotiation and is loosely
based on the Enlightenment "session recovery" protocol which has been
implemented and functional for roughly two years

some further reading: https://blogs.s-osg.org/recovery-journey-discovery/

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 Makefile.am|   1 +
 unstable/xdg-session-management/README |   4 +
 .../xdg-session-management-unstable-v1.xml | 181 +
 3 files changed, 186 insertions(+)
 create mode 100644 unstable/xdg-session-management/README
 create mode 100644 
unstable/xdg-session-management/xdg-session-management-unstable-v1.xml

diff --git a/Makefile.am b/Makefile.am
index 4b9a901..2b75114 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -17,6 +17,7 @@ unstable_protocols =  
\

unstable/keyboard-shortcuts-inhibit/keyboard-shortcuts-inhibit-unstable-v1.xml \
unstable/xdg-output/xdg-output-unstable-v1.xml  
\
unstable/input-timestamps/input-timestamps-unstable-v1.xml  \
+   unstable/xdg-session-management/xdg-session-management-unstable-v1.xml  
\
$(NULL)
 
 stable_protocols = 
\
diff --git a/unstable/xdg-session-management/README 
b/unstable/xdg-session-management/README
new file mode 100644
index 000..7bff401
--- /dev/null
+++ b/unstable/xdg-session-management/README
@@ -0,0 +1,4 @@
+xdg session management protocol
+
+Maintainers:
+Mike Blumenkrantz <zm...@osg.samsung.com>
diff --git 
a/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml 
b/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml
new file mode 100644
index 000..0c36c16
--- /dev/null
+++ b/unstable/xdg-session-management/xdg-session-management-unstable-v1.xml
@@ -0,0 +1,181 @@
+
+
+  
+Copyright 2018 Mike Blumenkrantz
+Copyright 2018 Samsung Electronics Co., Ltd
+Copyright 2018 Red Hat Inc.
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+  
+Warning! The protocol described in this file is experimental and backward
+incompatible changes may be made. Backward compatible changes may be added
+together with the corresponding interface version bump. Backward
+incompatible changes are done by bumping the version number in the protocol
+and interface names and resetting the interface version. Once the protocol
+is to be declared stable, the 'z' prefix and the version number in the
+protocol and interface names are removed and the interface version number 
is
+reset.
+  
+  
+
+  The xdg_session_manager interface defines base requests for creating and
+  managing a session for an application. Sessions persist across 
application
+  and compositor restarts unless explicitly destroyed. A session is created
+  for the purpose of maintaining an application's xdg_toplevel surfaces
+  across compositor or application restarts. The compositor should remember
+  as many states as possible for surfaces in a given session, but there is
+  no requirement for which states must be remembered.
+
+
+  
+   This has no effect other than to destroy the xdg_session_manager object.
+  
+
+
+  
+Create a session object corresponding to the given session
+identifier stri

[PATCH] xdg-shell: remove harmless typo

[Mike Blumenkrantz]

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 stable/xdg-shell/xdg-shell.xml | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/stable/xdg-shell/xdg-shell.xml b/stable/xdg-shell/xdg-shell.xml
index dc70c7a..d524ea9 100644
--- a/stable/xdg-shell/xdg-shell.xml
+++ b/stable/xdg-shell/xdg-shell.xml
@@ -555,7 +555,7 @@
 
   
Set the "parent" of this surface. This surface should be stacked
-   this above the parent surface and all other ancestor surfaces.
+   above the parent surface and all other ancestor surfaces.
 
Parent windows should be set on dialogs, toolboxes, or other
"auxiliary" surfaces, so that the parent is raised when the dialog
-- 
2.13.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Future of xdg-shell v5 support in weston

[Mike Blumenkrantz]

I think that keeping it only promotes using it and further propagating its
use, so I'm in favor of removal.

On Fri, Jan 19, 2018 at 11:22 AM Derek Foreman 
wrote:

> Hello,
>
> As you all may know, xdg-shell v5 and xdg-shell stable can't currently
> co-exist in the same compositor, as both define structures with the same
> name (such as struct xdg_surface_interface).
>
> A solid effort was made to add functionality to wayland-scanner to
> resolve this, but turned out to be a Very Hard Problem:
>
> https://lists.freedesktop.org/archives/wayland-devel/2018-January/036549.html
>
> Is a good summary of where that patch series currently sits.
>
> That leaves us with a bit of a problem - weston currently support
> xdg-shell v5, and that's blocking any chance of adopting xdg-shell final.
>
> It's my opinion that supporting xdg-shell final is rather important for
> the wayland reference compositor.
>
> So, I think we need to consider removing xdg-shell v5 from weston and
> its included clients as soon as is reasonable.
>
> It should probably be considered deprecated since the introduction of
> xdg-shell v6 into wayland-protocols in late 2015.  I'm sure there are
> still users out there, but it has always been labeled "unstable" with a
> firm promise that it would disappear eventually.
>
> Do we have any opinions on when we can strip this out?  I think keeping
> it for the next release and removing it immediately after is pragmatic
> (with a firm warning in the release notes that this is coming).
>
> Myself, I'd be happy to start drafting patches to remove it immediately
> - weston isn't intended to be anyone's desktop, so I don't think
> arguments that some released software will fail to run on weston should
> be given substantial weight...
>
> Also, I don't think toytoolkit clients failing to connect to a
> compositor that only has v5 support is a major concern either.
>
> Thanks,
> Derek
> ___
> 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

Re: [PATCH] Add the KDE server decoration protocol

[Mike Blumenkrantz]

Hi,

Sorry I'm late to the review on this, I've been on an extended vacation.

On Wed, Nov 15, 2017 at 8:01 AM David Edmundson 
wrote:

> On Mon, Oct 30, 2017 at 5:03 AM, Jonas Ådahl  wrote:
>
>> On Fri, Oct 27, 2017 at 01:13:15PM +0100, David Edmundson wrote:
>> > The server decoration protocol negotiates between the client and server
>> > whether the client should default to drawing window decorations, and
>> > informs the compositor what the client is doing.
>> >
>> > This is useful not just for a compostior that is doing decorations
>> > itself, but much more importantly for a toolkit, such as Qt which
>> > primarily targets embedded and IVI applications, not to have to modify
>> > clients
>> > to add a header bar which makes them usable on a desktop compositor.
>> >
>> > This file is currently copied in multiple places across GTK, Sway as
>> well
>> > as being needed in both Qt and KDE. We should have this in a shared
>> > place.
>>
>> I think that this functionality is in scope for wayland-protocols, but
>> wayland-protocols was AFAIK never meant as a distribution of arbitrary
>> external protocols. In the beginning, a major reason why it was created
>> at all was because wayland.xml was getting too large and it was too
>> inconvenient to wait for wayland releases for adding a new protocol or
>> protocol version would we instead add new XML files to the wayland repo.
>>
>> I'd expect protocols that aim to be included here to be willing to go
>> through protocol review and adhere to the conventions we have set up.
>> I have read through the protocol and will provide feedback as if the
>> protocol aims to follow the conventions we have in place.
>>
>
> Sounds reasonable.
> I understand you don't want to have a generic dumping ground.
>
> Thanks for the very thorough review.
>
>>
>> > ---
>> >  unstable/server-decoration/server-decoration.xml | 94
>> > 
>> >  1 file changed, 94 insertions(+)
>> >  create mode 100644 unstable/server-decoration/server-decoration.xml
>> >
>> > diff --git a/unstable/server-decoration/server-decoration.xml
>> > b/unstable/server-decoration/server-decoration.xml
>> > new file mode 100644
>> > index 000..8bc106c
>> > --- /dev/null
>> > +++ b/unstable/server-decoration/server-decoration.xml
>> > @@ -0,0 +1,94 @@
>> > +
>> > +
>> > +  
>> > +  > version="1">
>>
>> I believe a protocol related to window decorations belong in the "xdg"
>> family of protocols, extending 'xdg_wm_base'. For example
>> 'xdg_wm_window_decorations' could be the name of a window decoration
>> extension to xdg_wm_base (that is the main interface of xdg_shell).
>>
>
> Sure, my initial intention was to share the spec that's currently being
> used, rather than
> define something "xdg official".
>
> Long term the latter is probably better even if it is going to
> be more work for all involved.
>
>
>> > +  
>> > +This interface allows to coordinate whether the server should
>> > create
>> > +a server-side window decoration around a wl_surface
>> representing a
>> > +shell surface (wl_shell_surface or similar). By announcing
>> support
>> > +for this interface the server indicates that it supports server
>> > +side decorations.
>> > +  
>> > +  
>> > +
>> > +When a client creates a server-side decoration object it
>> > indicates
>> > +that it supports the protocol. The client is supposed to
>> tell
>> > the
>> > +server whether it wants server-side decorations or will
>> provide
>> > +client-side decorations.
>> > +
>> > +If the client does not create a server-side decoration
>> object
>> > for
>> > +a surface the server interprets this as lack of support for
>> > this
>> > +protocol and considers it as client-side decorated.
>> > Nevertheless a
>> > +client-side decorated surface should use this protocol to
>> > indicate
>> > +to the server that it does not want a server-side deco.
>>
>> What is the purpose of a client not supporting server side decorations
>> to create this object anyway? I assume functionality wise it shouldn't
>> make any difference right?
>>
>
> It shouldn't.
>

>> > +
>> > +> > interface="org_kde_kwin_server_decoration"/>
>> > +
>> > +  
>> > +  
>> > +
>> > +
>>
>> Why would a popup surface create a window decoration object at all? It
>> seems pointless. I might be missing something but it seems to only make
>> any sense to only deal with toplevels. A request creating the window
>> decoration object could for example require that a surface passed is 'an
>> xdg_toplevel or equivalent'.
>>
>
> You're right that a popup wouldn't need to.
> There are top levels that need it setting to 0. Like splash screens.
>
> The other issue we have is this doesn't attach to an xdg_toplevel/popup
> but to the
> 

Re: connection: add sanity check to avoid buffer overflow

[Mike Blumenkrantz]

On one hand it may be dangerous for the scenario that you've described, but
on the other hand why are you (or anyone) needing to call internal,
non-exported libwayland functions?

??

On Thu, Oct 19, 2017 at 3:11 AM Boram Park 
wrote:

>
>
> On 2017년 09월 28일 00:13, Derek Foreman wrote:
> > On 2017-09-26 10:46 AM, Sergi Granell wrote:
> >> On Thu, 2017-09-14 at 09:21 +0900, Boram Park wrote:
> >>> Before putting data into a buffer, we have to make sure that the data
> >>> size is
> >>> smaller than not only the buffer's full size but also the buffer's
> >>> empty
> >>> size.
> >>>
> >>> https://bugs.freedesktop.org/show_bug.cgi?id=102690
> >>>
> >>> Signed-off-by: Boram Park 
> >>> Acked-by: Pekka Paalanen 
> >>> ---
> >>>   src/connection.c | 9 ++---
> >>>   1 file changed, 6 insertions(+), 3 deletions(-)
> >>>
> >>> diff --git a/src/connection.c b/src/connection.c
> >>> index 5c3d187..53b1621 100644
> >>> --- a/src/connection.c
> >>> +++ b/src/connection.c
> >>> @@ -63,14 +63,17 @@ struct wl_connection {
> >>>   int want_flush;
> >>>   };
> >>>   +static uint32_t wl_buffer_size(struct wl_buffer *b);
> >>> +
> >>
> >> I think it would be a better idea to move the wl_buffer_size definition
> >> at the top to avoid this forward declaration.
> >>
> >>>   static int
> >>>   wl_buffer_put(struct wl_buffer *b, const void *data, size_t count)
> >>>   {
> >>> -uint32_t head, size;
> >>> +uint32_t head, size, empty;
> >>>   -if (count > sizeof(b->data)) {
> >>> +empty = sizeof(b->data) - wl_buffer_size(b);
> >>> +if (count > empty) {
> >>>   wl_log("Data too big for buffer (%d > %d).\n",
> >>> -   count, sizeof(b->data));
> >>> +   count, empty);
> >>>   errno = E2BIG;
> >>>   return -1;
> >>>   }
> >
> > I'm not sure I like this.  I've looked and all callers should already
> > have this check - are you actually getting here with this condition
> > somehow?
> looks it will never happen because all callers already check the data
> size before putting.
> > Also, the patch changes the meaning of E2BIG from the caller's
> > perspective (if we can even get here), doesn't it? Previously E2BIG
> > meant the packet could never fit, now it would mean that the packet
> > can't fit now.
> >
> > I think maybe just a comment mentioning that all the callers must
> > ensure the data will fit could be enough?
> However, it looks really dangerous for someone who don't know above rule
> that caller should check the buffer empty size before calling
> wl_buffer_put.
> comment might be helpful to understand the intention of developer who
> implemented this code.
> But the sanity check is much better to ensure safety, I think.
>
> >
> > I could even see an assert(), since this is a conditional that should
> > never fire.
> >
> > But I really don't like changing the meaning of the error code.
> >
> > Thanks,
> > Derek
> >
> >> Other than that,
> >>
> >> Reviewed-by: Sergi Granell 
> >> ___
> >> 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
>
> ___
> 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

Re: [PATCH wayland 8/9] client: Replace the singleton zombie with bespoke zombies

[Mike Blumenkrantz]

On Tue, Apr 11, 2017 at 11:39 AM Derek Foreman 
wrote:

> On 07/04/17 03:27 PM, Derek Foreman wrote:
> > Using the singleton zombie object doesn't allow us to posthumously retain
> > object interface information, which makes it difficult to properly inter
> > future events destined for the recently deceased proxy.
> >
> > Notably, this makes it impossible for zombie proxy destined file
> > descriptors to be properly consumed.
> >
> > Instead of having a singleton zombie object, we add a new wl_map flag
> > (valid only on the client side where zombies roam - the existing
> > "legacy" flag was only ever used on the server side) to indicate that a
> > map entry is now a zombie.
> >
> > We still have to refcount and potentially free the proxy immediately or
> > we're left with situations where it can be leaked forever.  If we clean
> > up on delete_id, for example, a forced disconnect will result in a leaked
> > proxy (breaking much of the test suite).
> >
> > So, since we must free the zombied proxy immediately, we store just the
> > interface for it in its previous map location, so signature information
> > can be retained for zombie-destined events.
>
> So even with this in place it's still possible for a malicious
> application to consume 1000fds (the number of fds that fit in fds_in)
>

ITYM 1024 but I understood what you meant


> and go to sleep and hold them - on client disconnect they should be
> freed.  I don't really see a way to prevent that sort of crap anyway - a
> client could use sendmsg directly, send a single byte of regular data
> (ie: not enough to trigger demarshalling, the server will assume there's
> more to come), and a buffer's worth of file descriptors, then never
> speak again.
>
> This appears indistinguishable from reasonable behaviour?
>
> There's also an interesting side effect to this patch that I noticed
> yesterday - it places a requirement on the client to keep the
> wl_interfaces around in memory long after it destroys the proxy - up
> until the delete_id occurs.  We have no way to hook delete_id in the
> client.  This turned into a crash in EFL clients using the text input
> protocol, as the input method code in EFL is a module that's unloaded on
> shutdown.  It was easily fixed in EFL, but I'd like some input - is a
> client allowed to unmap the memory that a wl_interface is stored in at
> the moment it deletes the relevant proxy?
>
> This isn't terribly difficult to fix, but I won't bother if the
> behaviour is universally concluded to be a client bug. :)
>
> Oh, and I just noticed wl_map_set_flags() is in this patch - that's a
> remnant of a previous attempt to close this leak, and will be removed
> for v2.
>
> Thanks,
> Derek
>
> > Signed-off-by: Derek Foreman 
> > ---
> >  src/connection.c  | 20 +++-
> >  src/wayland-client.c  | 10 ++
> >  src/wayland-private.h | 12 
> >  src/wayland-util.c| 22 --
> >  4 files changed, 53 insertions(+), 11 deletions(-)
> >
> > diff --git a/src/connection.c b/src/connection.c
> > index f2ebe06..84f5d79 100644
> > --- a/src/connection.c
> > +++ b/src/connection.c
> > @@ -809,6 +809,24 @@ wl_connection_demarshal(struct wl_connection
> *connection,
> >   return NULL;
> >  }
> >
> > +bool
> > +wl_object_is_zombie(struct wl_map *map, uint32_t id)
> > +{
> > + uint32_t flags;
> > +
> > + if (map->side == WL_MAP_SERVER_SIDE)
> > + return false;
> > +
> > + if (id >= WL_SERVER_ID_START)
> > + return false;
> > +
> > + flags = wl_map_lookup_flags(map, id);
> > + if (flags & WL_MAP_ENTRY_ZOMBIE)
> > + return true;
> > +
> > + return false;
> > +}
> > +
> >  int
> >  wl_closure_lookup_objects(struct wl_closure *closure, struct wl_map
> *objects)
> >  {
> > @@ -830,7 +848,7 @@ wl_closure_lookup_objects(struct wl_closure
> *closure, struct wl_map *objects)
> >   closure->args[i].o = NULL;
> >
> >   object = wl_map_lookup(objects, id);
> > - if (object == WL_ZOMBIE_OBJECT) {
> > + if (wl_object_is_zombie(objects, id)) {
> >   /* references object we've already
> >* destroyed client side */
> >   object = NULL;
> > diff --git a/src/wayland-client.c b/src/wayland-client.c
> > index 7243d3d..2cd713d 100644
> > --- a/src/wayland-client.c
> > +++ b/src/wayland-client.c
> > @@ -408,8 +408,10 @@ proxy_destroy(struct wl_proxy *proxy)
> >   if (proxy->flags & WL_PROXY_FLAG_ID_DELETED)
> >   wl_map_remove(>display->objects, proxy->object.id);
> >   else if (proxy->object.id < WL_SERVER_ID_START)
> > - wl_map_insert_at(>display->objects, 0,
> > -  proxy->object.id, WL_ZOMBIE_OBJECT);
> > + wl_map_insert_at(>display->objects,
> > +   

Re: [PATCH weston] weston-terminal: Add a --maximized command line parameter

[Mike Blumenkrantz]

I'd like to see this merged for use with spec testing in Enlightenment.

On Thu, Mar 9, 2017 at 3:50 PM Bryce Harrington 
wrote:

> On Wed, Mar 08, 2017 at 11:58:20AM -0600, Derek Foreman wrote:
> > This is useful for testing compositor response to a client that
> > requests a maximized initial surface.
> >
> > Signed-off-by: Derek Foreman 
>
> Reviewed-by: Bryce Harrington 
>
> > ---
> >  clients/terminal.c | 5 +
> >  1 file changed, 5 insertions(+)
> >
> > diff --git a/clients/terminal.c b/clients/terminal.c
> > index 5c25fa8d..c5531790 100644
> > --- a/clients/terminal.c
> > +++ b/clients/terminal.c
> > @@ -49,6 +49,7 @@
> >  #include "window.h"
> >
> >  static int option_fullscreen;
> > +static int option_maximize;
> >  static char *option_font;
> >  static int option_font_size;
> >  static char *option_term;
> > @@ -3048,6 +3049,8 @@ terminal_run(struct terminal *terminal, const char
> *path)
> >
> >   if (option_fullscreen)
> >   window_set_fullscreen(terminal->window, 1);
> > + else if (option_maximize)
> > + window_set_maximized(terminal->window, 1);
> >   else
> >   terminal_resize(terminal, 80, 24);
> >
> > @@ -3056,6 +3059,7 @@ terminal_run(struct terminal *terminal, const char
> *path)
> >
> >  static const struct weston_option terminal_options[] = {
> >   { WESTON_OPTION_BOOLEAN, "fullscreen", 'f', _fullscreen },
> > + { WESTON_OPTION_BOOLEAN, "maximized", 'm', _maximize },
> >   { WESTON_OPTION_STRING, "font", 0, _font },
> >   { WESTON_OPTION_INTEGER, "font-size", 0, _font_size },
> >   { WESTON_OPTION_STRING, "shell", 0, _shell },
> > @@ -3089,6 +3093,7 @@ int main(int argc, char *argv[])
> > ARRAY_LENGTH(terminal_options), , argv) >
> 1) {
> >   printf("Usage: %s [OPTIONS]\n"
> >  "  --fullscreen or -f\n"
> > +"  --maximized or -m\n"
> >  "  --font=NAME\n"
> >  "  --font-size=SIZE\n"
> >  "  --shell=NAME\n", argv[0]);
> > --
> > 2.11.0
> >
> > ___
> > 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
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston] terminal: Fix crash due to race condition in init

[Mike Blumenkrantz]

Hi,

Reverting this causes a 100% reproducible crash on startup in one of my CI
tests for weston-terminal. Here is some of the debugging info:

Program terminated with signal SIGSEGV, Segmentation fault.
#0  0x0040ab93 in handle_char (terminal=0x6348a0, utf8=...) at
clients/terminal.c:1991
1991 row[terminal->column] = utf8;
Missing separate debuginfos, use: dnf debuginfo-install
weston-1.12.0-1.fc25.x86_64
(gdb) bt
#0  0x0040ab93 in handle_char (terminal=0x6348a0, utf8=...) at
clients/terminal.c:1991
#1  0x0040b38d in terminal_data (terminal=0x6348a0,
data=0x7fffdb40 "sh-4.3$ ",
length=8) at clients/terminal.c:2172
#2  0x0040d296 in io_handler (task=0x6348c8, events=1) at
clients/terminal.c:3021
#3  0x00419d7f in display_run (display=0x62e8c0) at
clients/window.c:6506
#4  0x0040d5a2 in main (argc=1, argv=0x7fffde98) at
clients/terminal.c:3109
(gdb) p terminal->column
$1 = 0
(gdb) p row
$2 = (union utf8_char *) 0x0
(gdb) l
1986 row = terminal_get_row(terminal, terminal->row);
1987 attr_row = terminal_get_attr_row(terminal, terminal->row);
1988
1989 if (terminal->mode & MODE_IRM)
1990 terminal_shift_line(terminal, +1);
1991 row[terminal->column] = utf8;
1992 attr_row[terminal->column++] = terminal->curr_attr;
1993
1994 if (terminal->row + terminal->start + 1 > terminal->end)
1995 terminal->end = terminal->row + terminal->start + 1;
(gdb) p terminal->row
$3 = -1


On Fri, Sep 9, 2016 at 1:55 PM Quentin Glidic <
sardemff7+wayl...@sardemff7.net> wrote:

> On 09/09/2016 19:02, Derek Foreman wrote:
> > On 31/08/16 05:56 PM, Quentin Glidic wrote:
> >> On 30/08/2016 04:07, Yong Bakos wrote:
> >>> On Aug 29, 2016, at 4:28 PM, Bryce Harrington 
> >>> wrote:
> 
>  weston-terminal intermittently crashes on startup.  This occurs
> because
>  some parameters in the weston_terminal structure such as data_pitch,
>  don't get set to non-zero until the resize_handler() callback gets
>  triggered.  That callback makes a call to terminal_resize_cells(), to
>  calculate the proper values for these parameters.
> 
>  On occasion, the resize handler call is slow to resolve, and the
> program
>  proceeds to start processing characters for the terminal window.  With
>  the parameters defaulting to zero, certain calculations come out
> wrong,
>  leading the program to attempt to scroll the buffer when it shouldn't,
>  and thus follows the crash.
> 
>  Instead, force the call to terminal_resize_cells() during the init,
> with
>  some dummy defaults, to ensure the parameters are always non-zero.
> 
>  Fixes: https://bugs.freedesktop.org/show_bug.cgi?id=97539
>  Signed-off-by: Bryce Harrington 
> >>>
> >>> I couldn't replicate the issue, but the fix seems innocuous enough.
> >>> Someone with more experience should chime in, but this is:
> >>>
> >>> Reviewed-by: Yong Bakos 
> >>
> >>
> >> Don’t see any harm having it as a quick fix. I wonder if xdg_shell_v6
> >> initial configure can be used as a sync point for all this?
> >>
> >> Pushed:
> >> c6ae812..5c611d9  master -> master
> >
> > Hey, can we revert this immediately? :)
> > (Unless someone has a better patch for the problem - I haven't actually
> > seen that crash myself.)
> >
> > Turns out when you launch weston from a console with the drm backend,
> > then start a weston-terminal, it sets weston's controlling terminal to
> > be 20x5.  The ioctl() at the bottom of terminal_resize_cells() appears
> > to be hitting weston's control terminal.
> >
> > When you exit weston you get a really great surprise.
> >
> > My system has systemd-logind, but I see it when running from
> > weston-launch too...
>
> Sure, reverted:
> 6967f0e..e30b5fb  master -> master
>
> Cheers,
>
>
> >
> > Thanks,
> > Derek
> >
> >> Cheers,
> >>
> >>>
>  ---
>  clients/terminal.c | 1 +
>  1 file changed, 1 insertion(+)
> 
>  diff --git a/clients/terminal.c b/clients/terminal.c
>  index 6257cb7..34bc2c9 100644
>  --- a/clients/terminal.c
>  +++ b/clients/terminal.c
>  @@ -2976,6 +2976,7 @@ terminal_create(struct display *display)
>  cairo_surface_destroy(surface);
> 
>  terminal_resize(terminal, 20, 5); /* Set minimum size first */
>  +terminal_resize_cells(terminal, 20, 5);
>  terminal_resize(terminal, 80, 25);
> 
>  wl_list_insert(terminal_list.prev, >link);
>  --
>  1.9.1
> 
>  ___
>  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
> >>>
> >>
> >>
> >
>
>
> --
>
> Quentin “Sardem 

Re: [PATCH wayland v2] protocol: Clarify the behaviour of wl_surface.attach

[Mike Blumenkrantz]

On Tue, Feb 14, 2017 at 11:17 PM Jonas Ådahl  wrote:

> On Tue, Feb 14, 2017 at 10:20:06AM -0600, Derek Foreman wrote:
> > Attaching a NULL wl_buffer to a surface is not always valid, but
> > the previous text indicated it was.
> >
> > Instead, let's define what NULL attachment does for all the surface
> > roles defined in wayland.xml, stop giving a blanket definition of
> > its behavior in wl_surface.attach, and warn developers that they
> > should refer to other protocol documentation for a full understanding
> > of wl_surface.attach.
>
> Good to see these things cleared up. Have some comments on the wording
> below, and the "cursor" role behaviour seems still undefined when
> attaching a NULL buffer.
>
> >
> > Signed-off-by: Derek Foreman 
> > ---
> >
> > Changes from v1:
> >  pretty much everything - define NULL attach for wl_shell specifically
> >  and remove the generic statement from wl_surface.attach
> >  refer readers to "other documentation"
> >
> >  protocol/wayland.xml | 10 +++---
> >  1 file changed, 7 insertions(+), 3 deletions(-)
> >
> > diff --git a/protocol/wayland.xml b/protocol/wayland.xml
> > index 29b63be..1a76e60 100644
> > --- a/protocol/wayland.xml
> > +++ b/protocol/wayland.xml
> > @@ -1002,6 +1002,10 @@
> >the related wl_surface is destroyed. On the client side,
> >wl_shell_surface_destroy() must be called before destroying
> >the wl_surface object.
> > +
> > +  Attaching a NULL wl_buffer to a surface assigned a role by
> > +  wl_shell will remove the content from the surface after the
> > +  next commit.
>
> How is "removes the content" compared to unmaps? Does this mean a shell
> implementation need to keep track of the position when the shell surface
> is later remapped? That would be a new requirement that was previously
> undefined behaviour, and is not what mutter does at the moment.
>

Enlightenment does this.


>
> >  
> >
> >  
> > @@ -1324,6 +1328,9 @@
> >
> >   Set a buffer as the content of this surface.
> >
> > + The role of the surface influences the behaviour of attach,
> > + so this documentation is incomplete without further reading.
> > +
>
> Possible alternative wording, possibly in the end of the ,
> as it talks about things that is specified below:
>
> The effect committing an attached buffer to a surface depends on
> what role the surface has been or is going to be assigned to.
> See the corresponding role specification for further details.
>
> This makes read more as the behaviour of *attach* does not change, but
> the effect of having attached and committed a buffer.
>
>
> Jonas
>
> >   The new size of the surface is calculated based on the buffer
> >   size transformed by the inverse buffer_transform and the
> >   inverse buffer_scale. This means that the supplied buffer
> > @@ -1358,9 +1365,6 @@
> >   the surface contents. However, if the client destroys the
> >   wl_buffer before receiving the wl_buffer.release event, the surface
> >   contents become undefined immediately.
> > -
> > - If wl_surface.attach is sent with a NULL wl_buffer, the
> > - following wl_surface.commit will remove the surface content.
> >
> > allow-null="true"
> >  summary="buffer of surface contents"/>
> > --
> > 2.11.0
> >
> ___
> 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

[PATCH] xdg-shell: require popups to intersect with or be adjacent to parent surfaces

[Mike Blumenkrantz]

some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index e49d74f..1c0f924 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -118,7 +118,9 @@
   child surface relative to a parent surface. Rules can be defined to 
ensure
   the child surface remains within the visible area's borders, and to
   specify how the child surface changes its position, such as sliding along
-  an axis, or flipping around a rectangle.
+  an axis, or flipping around a rectangle. These positioner-created rules 
are
+  constrained by the requirement that a child surface must intersect with 
or
+  be at least partially adjacent to its parent surface.
 
   See the various requests for details about possible rules.
 
@@ -941,7 +943,8 @@
   The x and y arguments passed when creating the popup object specify
   where the top left of the popup should be placed, relative to the
   local surface coordinates of the parent surface. See
-  xdg_surface.get_popup.
+  xdg_surface.get_popup. An xdg_popup must intersect with or be at least
+  partially adjacent to its parent surface.
 
   The client must call wl_surface.commit on the corresponding wl_surface
   for the xdg_popup state to take effect.
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] xdg-shell: require that popups intersect with parent surfaces

[Mike Blumenkrantz]

some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index e49d74f..ab270b8 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -118,7 +118,9 @@
   child surface relative to a parent surface. Rules can be defined to 
ensure
   the child surface remains within the visible area's borders, and to
   specify how the child surface changes its position, such as sliding along
-  an axis, or flipping around a rectangle.
+  an axis, or flipping around a rectangle. These positioner-created rules 
are
+  constrained by the requirement that a child surface must intersect with 
its
+  parent surface.
 
   See the various requests for details about possible rules.
 
@@ -941,7 +943,7 @@
   The x and y arguments passed when creating the popup object specify
   where the top left of the popup should be placed, relative to the
   local surface coordinates of the parent surface. See
-  xdg_surface.get_popup.
+  xdg_surface.get_popup. An xdg_popup must intersect with its parent 
surface.
 
   The client must call wl_surface.commit on the corresponding wl_surface
   for the xdg_popup state to take effect.
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

[Mike Blumenkrantz]

Allowing clients to raise/lower has nothing to do with trust and everything
to do with control. If clients can affect stacking, they can affect the
compositor's window placement policy. Wayland is all about having the
compositor be in absolute control of this to the point of clients having
the perception of being sandboxed, hence why there is no method for windows
to set/request/know their position on screen.

I have no plans at this time to r-b any wayland-protocols addition which
allows direct client manipulation of window stacking, regardless of how
cleverly written it may be.

Specifying CSD titlebar regions is just going to lead to even more
complexity; if you're dead set on this, I'd suggest an extension which just
notifies the compositor when the titlebar has been clicked; the compositor
can then choose to take action based on its policies.

On Tue, Dec 6, 2016 at 3:51 PM Adam Goode <ago...@google.com> wrote:

> On Mon, Dec 5, 2016 at 11:11 AM, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
> To echo Jonas's comments, I'm also strongly opposed to adding window
> stacking manipulation to the xdg-shell protocol. It's already a mess
> handling windows which try to raise/focus themselves in X11, this is not an
> issue I want to handle under Wayland.
>
> EFL also has functionality in the toolkit for this on client-side, but it
> does nothing on Wayland and we discourage its use under X11.
>
> On Fri, Dec 2, 2016 at 11:25 AM Adam Goode <ago...@google.com> wrote:
>
> On Fri, Dec 2, 2016 at 1:29 AM, Jonas Ådahl <jad...@gmail.com> wrote:
>
> On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:
> > On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> >
> > > On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:
> > > > Hi,
> > > >
> > > > See https://bugzilla.redhat.com/show_bug.cgi?id=1349225 and
> > > > https://bugzilla.gnome.org/show_bug.cgi?id=767967
> > > >
> > > > When using Client Side Decorations, toolkits cannot bind raise or
> lower
> > > to
> > > > user actions. This binding is traditionally used in the "middle click
> > > > titlebar to lower" action, which no longer works with CSD on Wayland.
> > > > Additionally, when click-to-raise is disabled, a click on a CSD
> titlebar
> > > > will not raise the window.
> > > >
> > > > I would like to add 'raise' and 'lower' to xdg-shell. These requests
> will
> > > > take no arguments, similarly to 'set_maximized' (which is commonly
> bound
> > > to
> > > > double-click titlebar).
> > >
> > > A client should not be able to raise itself on demand like that.
> Usually
> > > when raising, what they actually wanted to do is get attention because
> > > something happened, and that is what an API is supposed to do. I think
> > > the last time this was discussed it was referred to as "present" or
> > > something. GTK+ have a private protocol for this until we have
> something
> > > else.
> > >
> > > Regarding 'lower', any reason why this cannot be made a compositor side
> > > modifier->middle-click kind of thing? It'd work on the whole window and
> > > it'd work on all clients without any need for any protocol. There has
> > > also been discussions about having a protocol for specifying a "window
> > > title area" kind of thing, which the compositor can handle with special
> > > care would so be needed.
> > >
> > >
> > The compositor side modifier->middle-click does work this way in mutter
> > today. Having support for bare clicks with special meaning in certain
> > regions is the more subtle case. What this means today is that if you
> > configure your compositor with no-raise-on-click (for the traditional X
> > behavior), then windows with CSD don't get raised when decorations are
> > clicked (unless you hold a modifier key).
> >
> > The idea of having a special title-bar area known to the compositor seems
> > worth pursuing, but that could be abused by clients. CSD blended the
> lines
> > between client and compositor roles, and X was happy to be permissive
> with
> > that situation. I'm glad Wayland is non-permissive by default, but it
> does
> > make things tricky.
>
> Right, and since the lines are now comparably blurry, I think it makes
> sense to move away from clients doing window management when we have the
> chance. Personally I'd vote for getting rid of the
> "middle-click-on-title-lowers" binding in mutter X11 SSD pat

Re: Proposal to add 'raise' and 'lower' to xdg-shell in wayland-protocols

[Mike Blumenkrantz]

To echo Jonas's comments, I'm also strongly opposed to adding window
stacking manipulation to the xdg-shell protocol. It's already a mess
handling windows which try to raise/focus themselves in X11, this is not an
issue I want to handle under Wayland.

EFL also has functionality in the toolkit for this on client-side, but it
does nothing on Wayland and we discourage its use under X11.

On Fri, Dec 2, 2016 at 11:25 AM Adam Goode  wrote:

> On Fri, Dec 2, 2016 at 1:29 AM, Jonas Ådahl  wrote:
>
> On Thu, Dec 01, 2016 at 09:28:11AM -0500, Adam Goode wrote:
> > On Thu, Dec 1, 2016 at 12:56 AM, Jonas Ådahl  wrote:
> >
> > > On Wed, Nov 30, 2016 at 12:04:33PM -0500, Adam Goode wrote:
> > > > Hi,
> > > >
> > > > See https://bugzilla.redhat.com/show_bug.cgi?id=1349225 and
> > > > https://bugzilla.gnome.org/show_bug.cgi?id=767967
> > > >
> > > > When using Client Side Decorations, toolkits cannot bind raise or
> lower
> > > to
> > > > user actions. This binding is traditionally used in the "middle click
> > > > titlebar to lower" action, which no longer works with CSD on Wayland.
> > > > Additionally, when click-to-raise is disabled, a click on a CSD
> titlebar
> > > > will not raise the window.
> > > >
> > > > I would like to add 'raise' and 'lower' to xdg-shell. These requests
> will
> > > > take no arguments, similarly to 'set_maximized' (which is commonly
> bound
> > > to
> > > > double-click titlebar).
> > >
> > > A client should not be able to raise itself on demand like that.
> Usually
> > > when raising, what they actually wanted to do is get attention because
> > > something happened, and that is what an API is supposed to do. I think
> > > the last time this was discussed it was referred to as "present" or
> > > something. GTK+ have a private protocol for this until we have
> something
> > > else.
> > >
> > > Regarding 'lower', any reason why this cannot be made a compositor side
> > > modifier->middle-click kind of thing? It'd work on the whole window and
> > > it'd work on all clients without any need for any protocol. There has
> > > also been discussions about having a protocol for specifying a "window
> > > title area" kind of thing, which the compositor can handle with special
> > > care would so be needed.
> > >
> > >
> > The compositor side modifier->middle-click does work this way in mutter
> > today. Having support for bare clicks with special meaning in certain
> > regions is the more subtle case. What this means today is that if you
> > configure your compositor with no-raise-on-click (for the traditional X
> > behavior), then windows with CSD don't get raised when decorations are
> > clicked (unless you hold a modifier key).
> >
> > The idea of having a special title-bar area known to the compositor seems
> > worth pursuing, but that could be abused by clients. CSD blended the
> lines
> > between client and compositor roles, and X was happy to be permissive
> with
> > that situation. I'm glad Wayland is non-permissive by default, but it
> does
> > make things tricky.
>
> Right, and since the lines are now comparably blurry, I think it makes
> sense to move away from clients doing window management when we have the
> chance. Personally I'd vote for getting rid of the
> "middle-click-on-title-lowers" binding in mutter X11 SSD paths rather
> than adding it to GTK+.
>
>
> Unfortunately, it is in GTK+ for a while now. We have duplication between
> Mutter and GTK+, CSD required GTK+ to directly implement these features.
> Example: https://github.com/GNOME/gtk/blob/master/gtk/gtkwindow.c#L1372
>
> This duplication is unfortunate. Hopefully it could be resolved someday.
>
>
>
> >
> > I would really like to avoid having direct ways for a client to
> > > interfere with the window stacking, and especially not ones that
> require
> > > round trips.
> > >
> > >
> > As an alternative, what do you think of a raise/lower protocol that
> > required evidence of a click to trigger? The client could decide on its
> own
> > which buttons did what on which region of its surface (necessary for
> CSD),
> > but prove to the compositor that a click of some kind actually occurred.
> >
>
> There is still no reason why a client needs to have the ability to raise
> itself when it can communicate what it actually wanted. IIRC the
> "present" proposal used input event serials (i.e. allowed the compositor
> to match against a click/touch/...) at its discretion.
>
>
>
> I will have to look at the "present" proposal. Thanks for your comments.
>
>
>
> Jonas
>
> >
> >
> > > >
> > > > Is there any objection to adding these to xdg-shell, or should I
> > > > investigate another solution?
> > > >
> > >
> > > xdg-shell is in a state where I don't think we should add anything that
> > > is not very crucial until we have managed to declare it stable. A thing
> > > like lower/raise, which has been discussed plenty of times and is on
> the
> > > more controversial side, should not 

Re: [PATCH] xdg-shell: clarify popup constrain's slide mechanism

[Mike Blumenkrantz]

On Wed, 23 Nov 2016 12:05:12 -0800
Bill Spitzak <spit...@gmail.com> wrote:

> Much better to just say one of the "constraints" is that the child
> must touch the parent.
> 
> The specified api, despite attempts to prevent it, still allows
> starting positions that don't touch the parent (this can be achieved
> by using the offset, the restriction that the anchor rectangle be
> inside the parent does not help). So changing the definition of
> "constraints" to this would allow a position to fail if it does not
> touch, even before "sliding".
> 
> 
> On Mon, Nov 21, 2016 at 3:52 AM, Jonas Ådahl <jad...@gmail.com> wrote:
> > On Mon, Nov 21, 2016 at 06:36:49AM -0500, Mike Blumenkrantz wrote:  
> >> On Fri, 18 Nov 2016 09:28:56 +0800
> >> Jonas Ådahl <jad...@gmail.com> wrote:
> >>  
> >> > On Wed, Nov 16, 2016 at 10:23:59AM -0500, Mike Blumenkrantz wrote:  
> >> > > some restrictions must be placed on this or else it becomes legal for
> >> > > the compositor to place popups in unexpected locations when sliding
> >> > > is allowed
> >> > >
> >> > > Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> >> > > ---
> >> > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
> >> > >  1 file changed, 4 insertions(+), 2 deletions(-)
> >> > >
> >> > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> >> > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> >> > > index 6053e3c..30cdaeb 100644
> >> > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> >> > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> >> > > @@ -256,7 +256,8 @@
> >> > >
> >> > >
> >> > >   
> >> > > -   Slide the surface along the x axis until it is no longer 
> >> > > constrained.
> >> > > +   Slide the surface along the x axis within the toplevel surface 
> >> > > until it
> >> > > +   is no longer constrained.  
> >> >
> >> > This would break chained popup menus in GTK+. For example a menu chain
> >> > where eventually a menu now completely outside of the toplevel window
> >> > region hits the edge of monitor, and is supposed to slide (see
> >> > screenshot [0]).
> >> >
> >> > So I think we should just limit the way we can slide in relation to the
> >> > parent. Maybe we should rather put the limitations somewhere more
> >> > generic? I.e. a popup can only ever be positioned so that its window
> >> > geometry "touches" (where touches means that there will be no space in
> >> > between) its parent window geometry, or something like that?
> >> >
> >> >
> >> > Jonas
> >> >
> >> >
> >> > [0] 
> >> > https://people.freedesktop.org/~jadahl/menu-slide-outside-of-toplevel.png
> >> >  
> >>
> >> Hm, while I strongly disagree with any application design that requires 
> >> this level of submenu chaining, I can see why we might need to support at 
> >> least basic submenu positioning outside the toplevel. I think changing 
> >> "toplevel" to "parent" in my patch would address that sufficiently?  
> >
> > It sounds like the "sliding within the parent" means the whole child
> > surface must be within the parent, which is not the case. Maybe better
> > with "Slide the surface along the x/y axis until it is no longer
> > constrained or doesn't touch the parent surface anymore." or something.
> >
> >
> > Jonas
> >  
> >>  
> >> > >
> >> > > First try to slide towards the direction of the gravity on the x 
> >> > > axis
> >> > > until either the edge in the opposite direction of the gravity is
> >> > > @@ -271,7 +272,8 @@
> >> > >
> >> > >
> >> > >   
> >> > > -   Slide the surface along the y axis until it is no longer 
> >> > > constrained.
> >> > > +   Slide the surface along the y axis within the toplevel surface 
> >> > > until it
> >> > > +   is no longer constrained.
> >> > >
> >> > > First try to slide towards the direction of the gravity on the y 
> >> > > axis
> >> > > until either the edge in the opposite direction of the gravity is
> >> > > --
> >> > > 2.5.5
> >> > >
> >> > > ___
> >> > > 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 is a good suggestion. I'll send a new patch which makes a statement about 
popups being at least adjacent to the parent in some way.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: clarify popup constrain's slide mechanism

[Mike Blumenkrantz]

On Fri, 18 Nov 2016 09:28:56 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> On Wed, Nov 16, 2016 at 10:23:59AM -0500, Mike Blumenkrantz wrote:
> > some restrictions must be placed on this or else it becomes legal for
> > the compositor to place popups in unexpected locations when sliding
> > is allowed
> > 
> > Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> > ---
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
> >  1 file changed, 4 insertions(+), 2 deletions(-)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 6053e3c..30cdaeb 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -256,7 +256,8 @@
> >
> >
> > 
> > - Slide the surface along the x axis until it is no longer constrained.
> > + Slide the surface along the x axis within the toplevel surface until 
> > it
> > + is no longer constrained.  
> 
> This would break chained popup menus in GTK+. For example a menu chain
> where eventually a menu now completely outside of the toplevel window
> region hits the edge of monitor, and is supposed to slide (see
> screenshot [0]).
> 
> So I think we should just limit the way we can slide in relation to the
> parent. Maybe we should rather put the limitations somewhere more
> generic? I.e. a popup can only ever be positioned so that its window
> geometry "touches" (where touches means that there will be no space in
> between) its parent window geometry, or something like that?
> 
> 
> Jonas
> 
> 
> [0] https://people.freedesktop.org/~jadahl/menu-slide-outside-of-toplevel.png
> 

Hm, while I strongly disagree with any application design that requires this 
level of submenu chaining, I can see why we might need to support at least 
basic submenu positioning outside the toplevel. I think changing "toplevel" to 
"parent" in my patch would address that sufficiently?

> >  
> >   First try to slide towards the direction of the gravity on the x axis
> >   until either the edge in the opposite direction of the gravity is
> > @@ -271,7 +272,8 @@
> >
> >
> > 
> > - Slide the surface along the y axis until it is no longer constrained.
> > + Slide the surface along the y axis within the toplevel surface until 
> > it
> > + is no longer constrained.
> >  
> >   First try to slide towards the direction of the gravity on the y axis
> >   until either the edge in the opposite direction of the gravity is
> > -- 
> > 2.5.5
> > 
> > ___
> > 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

Re: [PATCH] xdg-shell: clarify popup constrain's slide mechanism

[Mike Blumenkrantz]

Some background:

I was implementing v6 over the past few days and noticed, while handling
constraints, that this was a hugely problematic scenario. If a popup was
constrained in a particular way, the compositor could conceivably place it
on the opposite side of the screen over unrelated windows--certainly not
good behavior.

Clamping to the overall toplevel in some way seems pretty sane; popups must
originate from the toplevel (even nested popups), so forcing them to in
some way remain within the toplevel, even if it's only touching the
toplevel by a 1x1 rect, will preserve that relationship.

On Wed, Nov 16, 2016 at 10:24 AM Mike Blumenkrantz <zm...@osg.samsung.com>
wrote:

> some restrictions must be placed on this or else it becomes legal for
> the compositor to place popups in unexpected locations when sliding
> is allowed
>
> Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 6053e3c..30cdaeb 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -256,7 +256,8 @@
>
>
> 
> - Slide the surface along the x axis until it is no longer
> constrained.
> + Slide the surface along the x axis within the toplevel surface
> until it
> + is no longer constrained.
>
>   First try to slide towards the direction of the gravity on the x
> axis
>   until either the edge in the opposite direction of the gravity is
> @@ -271,7 +272,8 @@
>
>
> 
> - Slide the surface along the y axis until it is no longer
> constrained.
> + Slide the surface along the y axis within the toplevel surface
> until it
> + is no longer constrained.
>
>   First try to slide towards the direction of the gravity on the y
> axis
>   until either the edge in the opposite direction of the gravity is
> --
> 2.5.5
>
> ___
> 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

[PATCH] xdg-shell: clarify popup constrain's slide mechanism

[Mike Blumenkrantz]

some restrictions must be placed on this or else it becomes legal for
the compositor to place popups in unexpected locations when sliding
is allowed

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 6053e3c..30cdaeb 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -256,7 +256,8 @@
   
   

- Slide the surface along the x axis until it is no longer constrained.
+ Slide the surface along the x axis within the toplevel surface until 
it
+ is no longer constrained.
 
  First try to slide towards the direction of the gravity on the x axis
  until either the edge in the opposite direction of the gravity is
@@ -271,7 +272,8 @@
   
   

- Slide the surface along the y axis until it is no longer constrained.
+ Slide the surface along the y axis within the toplevel surface until 
it
+ is no longer constrained.
 
  First try to slide towards the direction of the gravity on the y axis
  until either the edge in the opposite direction of the gravity is
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 2/4 v2] xdg-shell: Clarify focus semantics for popup grabs

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Fri, Jul 29, 2016 at 12:06 AM Jonas Ådahl <jad...@gmail.com> wrote:

> Make it clearer what the focus semantics are during a popup grab. In
> short, when a grabbing popup is mapped, the top most popup will always
> have keyboard focus, while pointer and touch focus works just as normal
> except that only surfaces from the grabbing client will receive pointer
> and touch focus.
>
> This patch doesn't really change any semantics but rather clarifies
> what was ambiguous before.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>
> Changes since v1:
>
>   - Added back the "This is done so that ..." sentence.
>
>
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 8 +---
>  1 file changed, 5 insertions(+), 3 deletions(-)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 1d59a0e..2c8f636 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -1012,9 +1012,11 @@
> popup will be immediately dismissed. If the parent is a popup that
> did
> not take an explicit grab, an error will be raised.
>
> -   Clients will receive events for all their surfaces during this grab
> -   (which is an "owner-events" grab in X11 parlance). This is done so
> that
> -   users can navigate through submenus and other "nested" popup
> windows
> +   During a popup grab, the client owning the grab will receive
> pointer
> +   and touch events for all their surfaces as normal (similar to an
> +   "owner-events" grab in X11 parlance), while the top most grabbing
> popup
> +   will always have keyboard focus. This is done so that users can
> +   navigate through submenus and other "nested" popup windows
> without having to dismiss the topmost popup.
>
>
> --
> 2.7.4
>
> ___
> 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

Re: [PATCH wayland-protocols v2] Introduce xdg-foreign protocol

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Wed, Jul 27, 2016 at 3:55 AM Jonas Ådahl <jad...@gmail.com> wrote:

> xdg-foreign is a protocol meant to enable setting up inter surface
> relationships across clients. Potential use cases are out-of-process
> dialogs, such as file dialogs, meant to be used by sandboxed processes
> that may not have the access it needs to implement such dialogs.
>
> It works by enabling a client to export a surface, creating a handle
> for the exported surface. The handle, in form of a unique string, may
> be shared in some way with other clients (for example the provider of
> the file dialog) which can then import the exported surface.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>
> Changes since v1:
>
>  - Spelling and grammar fixes
>  - Wording changes (unexport -> revoke)
>  - Fixed the "Warning! .. unstable .." paragraph (was an old version)
>  - Added sandbox client -> unsandboxed file browser dialog example to
> protocol
>description
>  - Removed left-over note about restriction of importing a handle only
> once. It
>should be possible to import a handle multiple times, but the protocol
> text
>had only been updated in one of two places.
>
>
> Jonas
>
>
>
>  Makefile.am  |   1 +
>  unstable/xdg-foreign/README  |   4 +
>  unstable/xdg-foreign/xdg-foreign-unstable-v1.xml | 186
> +++
>  3 files changed, 191 insertions(+)
>  create mode 100644 unstable/xdg-foreign/README
>  create mode 100644 unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
>
> diff --git a/Makefile.am b/Makefile.am
> index 9e2a029..35df201 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -9,6 +9,7 @@ unstable_protocols =
>   \
> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml
>   \
> unstable/tablet/tablet-unstable-v1.xml
>   \
> unstable/tablet/tablet-unstable-v2.xml
>   \
> +   unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
>   \
> $(NULL)
>
>  stable_protocols =
>  \
> diff --git a/unstable/xdg-foreign/README b/unstable/xdg-foreign/README
> new file mode 100644
> index 000..f5bcb83
> --- /dev/null
> +++ b/unstable/xdg-foreign/README
> @@ -0,0 +1,4 @@
> +xdg foreign protocol
> +
> +Maintainers:
> +Jonas Ådahl <jad...@gmail.com>
> diff --git a/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> new file mode 100644
> index 000..c6f5775
> --- /dev/null
> +++ b/unstable/xdg-foreign/xdg-foreign-unstable-v1.xml
> @@ -0,0 +1,186 @@
> +
> +
> +
> +  
> +Copyright © 2015-2016 Red Hat Inc.
> +
> +Permission is hereby granted, free of charge, to any person obtaining
> a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without
> limitation
> +the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +and/or sell copies of the Software, and to permit persons to whom the
> +Software is furnished to do so, subject to the following conditions:
> +
> +The above copyright notice and this permission notice (including the
> next
> +paragraph) shall be included in all copies or substantial portions of
> the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR
> OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +This protocol specifies a way for making it possible to reference a
> surface
> +of a different client. With such a reference, a client can, by using
> the
> +interfaces provided by this protocol, manipulate the relationship
> between
> +its own surfaces and the surface of some other client. For example,
> stack
> +some of its own surface above the other clients surface.
> +
> +In order for a client A to get a reference of a surface of client B,
> client
> +B must first export its surface using xdg_exporter.export. Upon doing
> this,
> +client B will receive a handle (a unique string) that it ma

Re: [PATCH RFC] xdg-shell: Add tiled states

[Mike Blumenkrantz]

On Wed, Jun 1, 2016 at 10:42 AM 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'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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org

Re: [PATCH RFC] xdg-shell: Add tiled states

[Mike Blumenkrantz]

Hi,

On Wed, Jun 1, 2016 at 5:19 AM Olivier Fourdan  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 
> ---
>  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.
> 
> +  
> +   
> + 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.
> +   
> +  
> +  
> +   
> + 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.
> +   
> +  
> +  
> +   
> + 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.
> +   
> +  
> +  
> +   
> + 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.
> +   
>
>  
>
> --
> 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.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add draw states for xdg_surface

[Mike Blumenkrantz]

After a long weekend of not reading mails, I've read some mails; I'll try
to make comments to everything in this reply.

On Tue, May 31, 2016 at 7:38 AM Olivier Fourdan  wrote:

> Hey
>
> - Original Message -
> > On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
> > > [...]
> > > If we considered and dismissed them, fine.
> >
> > They are not "actively" considered in this patch, but as I mentioned
> > earlier, I think tiling states can later be added to the window state
> > enum.
>
> Just a quick note before my main power source goes down here, my comment
> are not about tiling, as stated before, I just tool tiling as an example of
> where we eanted to have a value per edge.
>
> FWIW, I don't think tiling is a "draw state", I reckon it's a plain state
> just like "maximized" or "active". But tiling is worth its own thread :)
>
> Cheers,
> Olviier
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


* Range allocations were added only because it was created in a similar way
to the configure state enum, which has such allocations. I don't care much
about them and I had no plans to use them at this time.

* This patch is solely about implementing the basic idea of "draw
states"--a method for negotiating and controlling the manner in which the
client draws its windows. I don't see a need to "define the issue" further
than "this is a new display server protocol, let's ensure there's a
standard way to negotiate/control drawing between the server and clients".
This is clearly different from window states due to 1) negotiation, and 2)
specifically related to drawing only, not behavior.
** The initial value of "no shadow" exists because it's a useful thing to
have in some cases (e.g., flat ui theme in compositor+toolkit, compositor
wants to draw special shadow effects, ...) and is not
controversial--moreover, it's trivial to implement compared to other
potential states.

The concept of draw states is easy to envision extensions for when provided
with this base example, and these extensions can be discussed at a later
time and in a separate thread if everyone can agree on the premise. A tiled
state is certainly something worthwhile to consider at that time and place.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add draw states for xdg_surface

[Mike Blumenkrantz]

On Sat, May 28, 2016 at 9:40 AM Yong Bakos <j...@humanoriented.com> wrote:

> Hi Mike,
> Regarding the combination of type="array" enum="foo"...
>
> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz <
> michael.blumenkra...@gmail.com> wrote:
>
> I've inlined some replies below.
>
> On Fri, May 27, 2016 at 1:13 PM Yong Bakos <j...@humanoriented.com> wrote:
>
>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz <zm...@osg.samsung.com>
>> wrote:
>> >
>> > this adds a method for compositors to change various draw attributes
>> > for a surface
>> >
>> > Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
>> > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
>>
>> Hi Mike & Jonas,
>> A question about communicating default state, and some
>> minor nits you can certainly ignore, inline below.
>>
>>
>> > ---
>> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69
>> 
>> > 1 file changed, 69 insertions(+)
>> >
>> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > index dfd7e84..0fa76d4 100644
>> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
>> > @@ -843,6 +843,75 @@
>> >   
>> > 
>> >
>> > +
>> > +  
>> > +The draw state enum defines optional states which describe how
>>
>> nit: that describe
>>
>
> "which" is correct and intended in this case.
>
>
>>
>> > +a client should draw a surface. A client must at least support
>> the
>> > +default state, and support for optional draw states is
>> explicitly
>> > +advertised using xdg_toplevel.set_available_draw_states.
>> > +
>> > +The default draw state implies that the client draws the
>> surface
>> > +with complete window decorations.
>>
>> nit: Same paragraph, so remove line break
>>
>
> Line break was intentional: documentation will not generate a line break,
> but anyone reading the protocol file will see it.
>
>
>>
>> > +This may include, e.g., window frame and drop shadow.
>> > +
>> > +Each draw state defines an alteration to the default. Some draw
>> > +states may be combined, while some are mutually exclusive. See
>> > +each draw state for details.
>> > +
>> > +Desktop environments may extend this enum by taking up a range
>> of
>> > +values and documenting the range they chose in this
>> description.
>> > +They are not required to document the values for the range
>> that they
>> > +chose. Ideally, any good extensions from a desktop environment
>> should
>>
>> nit: extension (singular)
>
>
>> > +make its way into standardization into this enum.
>> > +
>> > +The current reserved ranges are:
>> > +
>> > +0x - 0x0FFF: xdg-shell core values, documented below.
>> > +0x1000 - 0x1FFF: EFL
>> > +  
>>
>> should there be a 0 entry in the enum for default?
>> (see my comment re: empty array below)
>>
>
> Other state enums begin at 1.
>
>
>>
>> > +  
>> > +
>> > +  The "no_shadow" draw state implies that the client must not
>> draw
>>
>> nit: not draw a
>>
>
> Using "a" would imply that the drop shadow is a singular unit instead of a
> combination of multiple shadow regions--a possible case.
>
>
>>
>> > +  drop shadow around the surface. This may have side effects
>> > +  on usability, e.g., the inability to activate
>> client-initiated
>> > +  interactive resize.
>> > +
>> > +  
>> > +
>> > +
>> > +
>> > +  
>> > +Set the draw state(s) which the client should use to draw a
>> given
>>
>> nit: that the client should
>>
>
> "which" is correct and intended in this case.
>
>
>>
>> > +surface. The absence of this event prior to an
>> xdg_surface.configure
>> > +event indicates that no change has occurred in the draw state
>> since the
>> > +previous xdg

Re: [PATCH] xdg-shell: add draw states for xdg_surface

[Mike Blumenkrantz]

I've inlined some replies below.

On Fri, May 27, 2016 at 1:13 PM Yong Bakos <j...@humanoriented.com> wrote:

> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz <zm...@osg.samsung.com>
> wrote:
> >
> > this adds a method for compositors to change various draw attributes
> > for a surface
> >
> > Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
>
> Hi Mike & Jonas,
> A question about communicating default state, and some
> minor nits you can certainly ignore, inline below.
>
>
> > ---
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69
> 
> > 1 file changed, 69 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index dfd7e84..0fa76d4 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -843,6 +843,75 @@
> >   
> > 
> >
> > +
> > +  
> > +The draw state enum defines optional states which describe how
>
> nit: that describe
>

"which" is correct and intended in this case.


>
> > +a client should draw a surface. A client must at least support
> the
> > +default state, and support for optional draw states is
> explicitly
> > +advertised using xdg_toplevel.set_available_draw_states.
> > +
> > +The default draw state implies that the client draws the surface
> > +with complete window decorations.
>
> nit: Same paragraph, so remove line break
>

Line break was intentional: documentation will not generate a line break,
but anyone reading the protocol file will see it.


>
> > +This may include, e.g., window frame and drop shadow.
> > +
> > +Each draw state defines an alteration to the default. Some draw
> > +states may be combined, while some are mutually exclusive. See
> > +each draw state for details.
> > +
> > +Desktop environments may extend this enum by taking up a range
> of
> > +values and documenting the range they chose in this description.
> > +They are not required to document the values for the range that
> they
> > +chose. Ideally, any good extensions from a desktop environment
> should
>
> nit: extension (singular)


> > +make its way into standardization into this enum.
> > +
> > +The current reserved ranges are:
> > +
> > +0x - 0x0FFF: xdg-shell core values, documented below.
> > +0x1000 - 0x1FFF: EFL
> > +  
>
> should there be a 0 entry in the enum for default?
> (see my comment re: empty array below)
>

Other state enums begin at 1.


>
> > +  
> > +
> > +  The "no_shadow" draw state implies that the client must not
> draw
>
> nit: not draw a
>

Using "a" would imply that the drop shadow is a singular unit instead of a
combination of multiple shadow regions--a possible case.


>
> > +  drop shadow around the surface. This may have side effects
> > +  on usability, e.g., the inability to activate client-initiated
> > +  interactive resize.
> > +
> > +  
> > +
> > +
> > +
> > +  
> > +Set the draw state(s) which the client should use to draw a
> given
>
> nit: that the client should
>

"which" is correct and intended in this case.


>
> > +surface. The absence of this event prior to an
> xdg_surface.configure
> > +event indicates that no change has occurred in the draw state
> since the
> > +previous xdg_surface.configure.
> > +
> > +Sending an empty array of states with this method resets a
> surface to the
> > +default draw state.
>
> Would it not be more explicit for compositors to pass a "default" enum
> value rather
> than an empty array? (Assuming there is a default in the draw_state enum,
> per my
> comment above.)
> But, you will definitely know better than I!
>

This was discussed, and the resulting decision was that implementations
would be simplified if the default value never got passed here.


>
> > +
> > +This event is not sent by itself but as a latched state sent
> prior to
> > +the xdg_surface.configure event. When received, a client should
> adapt
> > +the drawing of the surface according to the state and re

[PATCH] xdg-shell: add draw states for xdg_surface

[Mike Blumenkrantz]

this adds a method for compositors to change various draw attributes
for a surface

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69 
 1 file changed, 69 insertions(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index dfd7e84..0fa76d4 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -843,6 +843,75 @@
   
 
 
+
+  
+The draw state enum defines optional states which describe how
+a client should draw a surface. A client must at least support the
+default state, and support for optional draw states is explicitly
+advertised using xdg_toplevel.set_available_draw_states.
+
+The default draw state implies that the client draws the surface
+with complete window decorations.
+This may include, e.g., window frame and drop shadow.
+
+Each draw state defines an alteration to the default. Some draw
+states may be combined, while some are mutually exclusive. See
+each draw state for details.
+
+Desktop environments may extend this enum by taking up a range of
+values and documenting the range they chose in this description.
+They are not required to document the values for the range that they
+chose. Ideally, any good extensions from a desktop environment should
+make its way into standardization into this enum.
+
+The current reserved ranges are:
+
+0x - 0x0FFF: xdg-shell core values, documented below.
+0x1000 - 0x1FFF: EFL
+  
+  
+
+  The "no_shadow" draw state implies that the client must not draw
+  drop shadow around the surface. This may have side effects
+  on usability, e.g., the inability to activate client-initiated
+  interactive resize.
+
+  
+
+
+
+  
+Set the draw state(s) which the client should use to draw a given
+surface. The absence of this event prior to an xdg_surface.configure
+event indicates that no change has occurred in the draw state since the
+previous xdg_surface.configure.
+
+Sending an empty array of states with this method resets a surface to 
the
+default draw state.
+
+This event is not sent by itself but as a latched state sent prior to
+the xdg_surface.configure event. When received, a client should adapt
+the drawing of the surface according to the state and respond to the
+configure event accordingly. See xdg_surface.ack_configure for
+details.
+
+A compositor will only configure a client to draw with optional states 
on a
+given surface using the states which were advertised by that surface 
using
+xdg_toplevel.set_available_draw_states.
+  
+  
+
+
+
+  
+Inform the compositor of optional draw states which are available
+for the xdg_toplevel.
+
+Calling this after an xdg_toplevel's first commit will raise a client 
error.
+  
+  
+
+
 
   
This configure event asks the client to resize its toplevel surface or
-- 
2.5.5

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: writing Was: [PATCH weston 1/5] gl-renderer: Rename gl_renderer_create to gl_renderer_display_create

[Mike Blumenkrantz]

On Wed, May 18, 2016 at 6:33 PM Yong Bakos <j...@humanoriented.com> wrote:

> Hi,
> I'm partly to blame for the bikeshedding on writing, yet believe me,
> I'm always asking "is this worth it?", prioritizing corrections/clarity
> over mere style judgements, and am definitely sensitive to
> everyone's cognitive bandwidth. My goal is high quality documentation
> for Wayland, and I am open to suggestions on how to best deliver that.
>
> (Maybe we can chat about this over IRC rather than further hijack this
> thread.)
>

Just to be clear, I think your work is worthwhile and valuable irregardless
of when in the development cycle it takes place. Without someone taking an
interest in alot of these matters, the codebase and documentation would be
literally unreadable, and I'm sure its not just myself who feels this way.


>
> On May 18, 2016, at 10:31 AM, Daniel Stone <dan...@fooishbar.org> wrote:
> >
> > Hi,
> >
> > On 18 May 2016 at 15:25, Derek Foreman <der...@osg.samsung.com> wrote:
> >> On 18/05/16 08:41 AM, Mike Blumenkrantz wrote:
> >>> In fairness, we'd likely be less short on review bandwidth if the
> >>> majority of that bandwidth was not in use to make/revise trivial
> >>> criticisms such as whitespace usage and comment grammar which are
> >>> guaranteed to be cleaned up in future patches; this leads to burnout on
> >>> both the code-writing side as well as the reviewing side since everyone
> >>> has become hyper attuned to the insignificant and non-functional
> >>> minutiae of patches rather than focusing more on expediting the
> >>> technical development of the protocol.
>
> I agree with the crux of Mike's point. Yet, should trivial correctness
> be revised before merging or should post-merge corrections clutter the
> blame history? (Rhetorical question.)
>

I'm more in favor of doing it post-merge even if it does add more entries
to the history. Wayland as a whole has a small number of people working on
and specializing in different areas, and the net result is that there's
relatively few people who are able to review/develop these areas. Bogging
down technical progress in order to perfect non-technical aspects will only
make it more frustrating for everyone involved and probably reduce future
interest in participating in the project.

Put more simply, it's much less hassle to locally `git blame` something
twice to adjust for cleanups than to submit and review a second draft of a
patch.


>
>
> >> Fair points, though I'm not certain "will certainly get fixed up later"
> >> is a given.  Certainly indenting and basic style is a mechanical problem
> >> that could be tested pre-commit hooks, and there should be no reason to
> >> bike shed that on the list at all.
>
> Yes!
>
>
> >> Grammar probably needs more serious consideration for protocol doc than
> >> elsewhere due to its potential impact on compositor implementors - but
> >> ever there probably not to the degree we're seeing lately.
> >>
> >> Follow up commits that do nothing but change style and grammar can make
> >> "git blame" less useful (when trying to figure out who would best review
> >> a piece of code - not just "agh who wrote this stupid bug") and
> >> provide churn for very little benefit, imho.
> >
> > Yeah, I agree. I get that the bikeshedding can be annoying; I do (for
> > that reason, if no other) like tagging commits as 'RFC' or similar,
> > which is effectively, 'please just check out the technical concept and
> > don't worry about memory leaks or spelling mistakes right now'. But
> > given that it's pretty trivial to fix up, and you're likely to have to
> > rebase _anyway_, I don't see the harm in doing one round of review for
> > clarity.
> >
> > Generally, there's no need to send out a subsequent revision round
> > just because someone has noted some typos - send it again if you need
> > a resend anyway to get people to pick it up after a rebase, or if
> > there have been notable changes, but you shouldn't be arriving at v17
> > just because you have difficulty spelling.
>
> Perhaps non-technical suggestions should be sent only directly to the
> author, for consideration in incorporating in the event of subsequent
> revisions, and we not send these to the list? This gives the author
> the benefit of the information, and does not clutter the list with
> non-technical reviews.
>

In line with my previous comments, I think providing patches after the fact
is sufficient here. These types of patches (outside of protocol-affecting
changes) can be reviewed by anyone and d

Re: [PATCH weston 1/5] gl-renderer: Rename gl_renderer_create to gl_renderer_display_create

[Mike Blumenkrantz]

On Wed, May 18, 2016 at 3:51 AM Pekka Paalanen  wrote:

> On Thu, 12 May 2016 17:20:49 +0200
> Miguel Angel Vico  wrote:
>
> > Thanks Derek.
> >
> > Inline.
> >
> > On Thu, 12 May 2016 08:54:26 -0500
> > Derek Foreman  wrote:
> >
> > > On 11/05/16 10:53 AM, Miguel Angel Vico wrote:
> > > > Thanks, Yong.
> > > >
> > > > Inline.
> > > >
> > > > On Wed, 11 May 2016 09:45:15 -0500
> > > > Yong Bakos  wrote:
> > > >
> > > >> On May 11, 2016, at 7:48 AM, Miguel A. Vico 
> > > >> wrote:
> > > >>>
> > > >>> No functional change. This patch only renames gl_renderer_create()
> > > >>> to gl_renderer_display_create(), which is something more
> > > >>> descriptive of what the function does.
> > > >>>
> > > >>> Signed-off-by: Miguel A Vico Moya 
> > > >>> Reviewed-by: James Jones 
> > > >>
> > > >> Hi Miguel,
> > > >> When renaming, I suggest adjusting the indentation of subsequent
> > > >> arguments as well, to preserve alignment. Example noted inline
> > > >> below. I'm noticing this issue throughout this whole patch
> > > >> series.
> > > >
> > > > The thing is arguments aren't correctly aligned throughout all
> > > > weston code. I think the code-style rule of using hard-tabs instead
> > > > of spaces for indentation made things to be a bit messy, since
> > > > arguments are usually aligned using hard-tabs as well, but I think
> > > > spaces should be used instead for those cases in order to keep a
> > > > correct indentation regardless tab length settings of the editor.
> > >
> > > The style of this weston source code is to use hard tabs, 8 chars
> > > wide. It won't look right in an editor configured with any other tab
> > > width.
> > >
> > > I'm with Yong on this one - if you're going to rename a function, it's
> > > preferable to fix up the indenting at the same time for those call
> > > sites (even if they didn't match the style guidelines before).  This
> > > fix-up should be done with tabs for alignment.
> > >
> > > Otherwise trivial refactoring patches would rapidly make the code look
> > > terrible.
> >
> > Okay, sounds sane to me too. I'll send an updated patch.
> >
> > >
> > > For what it's worth, I personally prefer tabs for indenting and spaces
> > > for alignment -
> >
> > I prefer spaces for everything, but I can live with tabs for
> > indenting and spaces for alignment :-)
> >
> > > but that's not what this project uses, so it's not
> > > what I use on this project. :)
> >
> > I double-checked code-style rules here:
> >
> >   https://cgit.freedesktop.org/wayland/wayland/tree/doc/Contributing
> >
> > and wrt alignment it only states:
> >
> >   - when breaking lines with functions calls, the parameters are aligned
> > with the opening parentheses;
> >
> > To me, that doesn't mean we shouldn't use spaces for alignment.
>
> Hi,
>
> as with all styles, there are exceptions.
>
> When breaking lines and aligning, it often does not happen exactly at a
> hard-tab boundary, so use spaces for the final adjustment.
>
> However, if any single argument to a function call cannot be reasonably
> fit by the alignment requirement without breaking the max line length,
> then (at least I have) you can forget the alignment to the opening
> parenthesis and just indent as far as you can and align there, using
> hard-tabs only.
>
> Sometimes it might be preferable to use shortcut variables, sometimes
> not. Rules can be bent if it is necessary for style consistency and
> readability. After all, the whole point of a style definition is to make
> things more readable to everyone on average, and almost always
> consistency in style helps that, so people should follow the project
> style rather than personal preferences.
>
> And yes, Weston does not rigorously follow the defined style to the
> point absolutely everywhere. Sometimes it is just better to land a v6
> of a patch than to go a few more review cycles to hone the style. Even
> reviewers can get tired of it, and we're usually short on review
> bandwidth anyway.
>

In fairness, we'd likely be less short on review bandwidth if the majority
of that bandwidth was not in use to make/revise trivial criticisms such as
whitespace usage and comment grammar which are guaranteed to be cleaned up
in future patches; this leads to burnout on both the code-writing side as
well as the reviewing side since everyone has become hyper attuned to the
insignificant and non-functional minutiae of patches rather than focusing
more on expediting the technical development of the protocol.


>
>
> Thanks,
> pq
> ___
> 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

Re: Protocol for window previews/thumbnails

[Mike Blumenkrantz]

On Thu, May 12, 2016 at 3:57 AM Pekka Paalanen  wrote:

> On Wed, 11 May 2016 23:35:01 +0100
> ade low  wrote:
>
> > Thank you for the feedback, that was very helpful.
> >
> > On Wed, May 11, 2016 at 9:07 AM, Pekka Paalanen 
> wrote:
> > >
> > >
> > > You should explain the use case behind the idea. Then it would be
> > > possible to assess whether such protocol would even be appropriate for
> > > it.
> > >
> >
> > My use case is third-party window switcher applications, such as
> > xfdashboard or my program, xfce4-lightdash-plugin:
> > https://github.com/adlocode/xfce4-lightdash-plugin
>
> The implementation of such things would have so much
> compositor-internal parts anyway, that making a protocol for it does
> not seem tractable to me. Why would anyone bother implementing such
> protocol in their compositor?
>
> > If some sort of protocol would be needed, then you have to figure out
> > > how to not make it a gaping security breach
> > >
> >
> > Perhaps the security could be improved by having a permissions system
> where
> > only authorised programs are allowed to use this protocol? Maybe the
> > compositor could expose a settings framework that allows the user to
> > control the permissions of applications.
>
> That is the hand-waving we have gone through several times before,
> without any solid and generic solution emerging yet. There are stabs at
> the issue, but nothing that is all of implemented, generic and widely
> accepted.
>
> The "there can be only one such client in a session" issue could be
> solved by the compositor launching the app with a pre-made,
> pre-authorized connection. That's how Weston does it.
>
> However, if instead of protocol, you'd have a plugin ABI in the
> compositor, that would be better on some aspects, but quite likely
> specific for each compositor. Supporting a generic plugin ABI falls
> down for many of the same reasons a standard protocol would.
>
> > A little more tractable plan would be to communicate only surface
> > > meta-data to the client, which could then ask the compositor to draw
> > > the thumbnails relative to one of the client's surfaces. The client
> > > would never have access to window content itself.
> >
> >
> > That's a good point; this could be a good solution, as long as it is
> > toolkit-independent and supports all rendering methods: OpenGL, pixman 2D
> > software rendering, etc.
>
> The very point is, the client would not render the thumbnails at all.
> The compositor would. Painting a copy of a window at another location
> should be fairly easy in theory. From your client perspective it would
> be a little like a special sub-surface whose content magically just
> appears on screen.
>
> >  However, then there's
> >
> > the question of whether it can be a standard protocol or not.
> >
> >
> > It is important that it is a standard, cross-compositor protocol. For
> > example, if I am using my app on "xfwm-wayland" and then I decide that I
> > want to switch to KWin, my app should continue to work.
>
> I would be very surprised if KWin developers would actually support
> that wish.
>
> FWIW, I do not believe at all, that the major DEs would implement
> support for adding third party DE components like what you want. They
> already have and develop their own stuff, and adding support for random
> third-party bits just makes for a huge maintenance addition.
>
> I could be wrong on that, but if I am, I will be surprised.
>

I can confirm that Enlightenment has no plans to implement anything like
this in the future.


>
> Your target audience would be the small DE or compositor projects who
> cannot build everything on their own.
>
> Even if you came up with a protocol design that also Wayland upstream
> saw as a good one (which is not exactly necessary, btw.), that still
> would not force anyone to implement it. There is no committee that
> decides what extensions everyone else must support. You have to sell
> your proposal to every DE project individually.
>
>
> Thanks,
> pq
> ___
> 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

Re: Introduction and updates from NVIDIA

[Mike Blumenkrantz]

On Wed, May 11, 2016 at 7:08 PM James Jones  wrote:

> On 05/11/2016 02:31 PM, Daniel Stone wrote:
> > Hi James,
> >
> > On 11 May 2016 at 21:43, James Jones  wrote:
> >> On 05/04/2016 08:56 AM, Daniel Stone wrote:
> >>> Right - but as with the point I was making below, GBM _right now_ is
> >>> more capable than Streams _right now_. GBM right now would require API
> >>> additions to match EGLStreams + EGLSwitch + Streams/KMS-interop, but
> >>> the last two aren't written either, so. (More below.)
> >>
> >> The current behavior that enables this, where basically all Wayland
> buffers
> >> must be allocated as scanout-capable, isn't reasonable on NVIDIA
> hardware.
> >> The requirements for scanout are too onerous.
> >
> > I think we're talking past each other, so I'd like to pare the
> > discussion down to these two sentences, and my two resultant points,
> > for now:
> >
> > I posit that the Streams proposal you (plural) have put forward is, at
> > best, no better at meeting these criteria:
> >- there is currently no support for direct scanout from client
> > buffers in Streams, so it must always pessimise towards GPU
> > composition
> >- GBM stacks can obviously do the same: implement a no-op
> > gbm_bo_import, and have your client always allocate non-scanout
> > buffers - presto, you've matched Streams
> >
> > I posit that GBM _can_ match the capability of a hypothetical
> > EGLStreams/EGLSwitch implementation. Current _implementations_ of GBM
> > cannot, but I posit that it is not a limitation of the API it exposes,
> > and unlike Streams, the capability can be plumbed in with no new
> > external API required.
> >
> > These seem pretty fundamental, so ... am I missing something? :\ If
> > so, can you please outline fairly specifically how you think
> > non-Streams implementations are not capable of meeting the criteria in
> > your two sentences?
>
> I respect the need to rein in the discussion, but I think several
> substantive aspects have been lost here.  I typed up a much longer
> response below, but I'll try to summarize in 4 sentences:
>
> GBM could match the allocation aspects of streams used in Miguel's first
> round of patches.  However, I disagree that its core API is sufficient
> to match the allocation capabilities of EGLStream+EGLSwitch where all
> producing and consuming devices+engines are known at allocation time.
> Further, streams have additional equally valuable functionality beyond
> allocation that GBM does not seem intended to address.  Absent
> agreement, I believe co-existence of EGLStreams and GBM+wl_drm in
> Wayland/Weston is a reasonable path forward in the short term.
>
> The longer version:
>
> GBM alone can not perform as well as EGLStreams unless it is extended
> into something more or less the same as EGLStreams, where it knows
> exactly what engines are being used to produce the buffer content (along
> with their current configuration), and exactly what
> engines/configuration are being used to consume it.  This implies
> allocating against multiple specific objects, rather than a device and a
> set of allocation modifier flags, and/or importing an external
> allocation and hoping it meets the current requirements.  From what I
> can see, GBM fundamentally understands at most the consumer side of the
> equation.
>
> Suppose however, GBM was taught everything streams know implicitly about
> all users of the buffers at allocation time.  After allocation, GBM is
> done with its job, but streams & drivers aren't.
>
> The act of transitioning a buffer from optimal "producer mode" to
> optimal "consumer mode" relies on all the device & config information as
> well, meaning it would need to be fed into the graphics driver (EGL or
> whatever window system binding is used) by each window system the
> graphics driver was running on to achieve equivalent capabilities to
> EGLStream.
>
> Fundamentally, the API-level view of individual graphics buffers as raw
> globally coherent & accessible stores of pixels with static layout is
> flawed.  Images on a GPU are more of a mutating spill space for a
> collection of state describing the side effects of various commands than
> a 2D array of pixels.  Forcing GPUs to resolve an image to a 2D array of
> pixels in any particular layout can be very inefficient.  The
> GL+GLX/EGL/etc. driver model hides this well, but it breaks down in a
> few cases like EGLImage and GLX_EXT_texture_from_pixmap, the former not
> really living up to its implied potential because of this, and the
> latter mostly working only because it has a very limited domain where
> things can be shared, but still requires a lot of platform-specific code
> to support properly.  Vulkan brings a lot more of this out into the open
> with its very explicit image state transitions and limitations on which
> engines can access an image in any given state, but that's just within
> the Vulkan API itself (I.e., strictly on a single GPU 

Re: Feedback on xdg-shell v5

[Mike Blumenkrantz]

On Fri, Apr 29, 2016 at 4:38 AM Martin Graesslin  wrote:

> On Thursday, April 28, 2016 5:36:58 PM CEST Jonas Ådahl wrote:
> > On Thu, Apr 28, 2016 at 10:36:14AM +0200, Martin Graesslin wrote:
> > > Hi Wayland and Plasma,
> > >
> > > I finished the implementation of xdg-shell in KWayland [1] and KWin
> [2].
> > > Overall it was more straight forward than I would have expected.
> > > Especially
> > > the changes to KWin were surprisingly minor (with one huge exception).
> > >
> > > Now some questions/remarks:
> > > * What's a server supposed to do in use_unstable_version?
> >
> > If a client requests the wrong version, the compositor should send an
> > error, effectively disconnecting the client.
> >
> > Note that this request is gone in v6 and is replaced by the same
> > unstable-protocol-version semantics used in wayland-protocols.
>
> Ok, that's what I though it is. I was just very unsure as killing the
> client
> is nothing I would consider "negotiate version" :-P
>
> >
> > > * Why is the ping on the shell and not on the surface? I would have
> > > expected to ping the surface. At least that's how I would want to do it
> > > from KWin.
> > Because you don't ping a surface, you ping the client. It's the client
> > that may be inresponsive, and if the client is in responsive, it's safe
> > to assume all its surfaces are as well.
>
> Sorry, but I doubt this will work in practice. I have experienced many
> freezes
> with QtWayland applications and in all cases it would respond to the ping.
> Consider:
> * Thread 1: dead-locked waiting for a frame callback
> * Thread 2: Wayland connection getting ping, thread alive, will send pong
>
> I fear that the concept of pinging clients doesn't work in a world where
> connections are in a thread.
>
> Anyway if it's about whether the client is responsive, I suggest to make
> it a
> dedicated protocol. It's not really something which belongs to xdg-shell,
> it's
> a more general concept.
>

I disagree that ping should be outside xdg-shell. The spec for this is
perfectly functional and has been successfully implemented by a number of
compositors/toolkits; claiming that you doubt its practicality based on
your choice to add complexity by using threads (and the bugs that you've
described in your implementation) is not a strong argument towards proving
that ping is not able to be successfully implemented.


>
> >
> > > * Would it be possible to split the states and geometry? I find it
> weird
> > > that I have to send a configure request with a size of 0/0 when
> informing
> > > a surface that it's active.
> >
> > Possible - yes, worth it? I don't know. It's clearly specified that
> > 0 means "let the client come up with it". If you think there is a clear
> > benefit, you're welcome to send a patch targeting v6.
>
> Yes, I think it might be worth it. I don't want that the client starts to
> think it can pick a different size when it becomes active.
>

Compositors can continue to send sizes for all configure events. There is
nothing in the spec which prohibits this behavior, it only says that sizes
may be omitted.


>
> >
> > > The biggest problem for me is the request set_window_geometry. I think
> I
> > > mentioned it already before on the wayland list. Basically I have no
> idea
> > > how to implement that in KWin. We have only one geometry for a window
> and
> > > that's mapped to the size of the surface/x11 pixmap. This geometry is
> > > used all over the place, for positioning, for resizing and for
> rendering.
> > > I cannot add support for this without either breaking code or having to
> > > introduce a new internal API. That's lots of work with high potential
> for
> > > breakage :-(
> > >
> > > From the description it seems to be only relevant for shadows. Could we
> > > make shadows an optional part in xdg-shell? That the server can
> announce
> > > that it supports shadows in the surface?
> >
> > It's not only about shadow. Let me explain a scenario where a window
> > geometry is needed, even when there is a mode where no shadow is drawn
> > by the client.
> >
> > Consider we have the following window:
> >
> >
> > +---+
> >
> > |   A window  X |
> >
> > +---+
> >
> > | /\|
> > |
> > |/  \   |
> > |
> > |   /\  |
> > |
> > |  /  \ |
> > |
> > | /\|
> >
> > +---+
> >
> > It can be split into two logical rectangles/areas: the window title, and
> > the main content. This window may be consisting of two separate
> > non-overlapping surfaces, for example one GLES surface, and one SHM
> > surface. Only one of these surfaces will be the "window", while the
> > other 

Re: [PATCH weston 3/4] data-device: Update current action even if source version is old

[Mike Blumenkrantz]

On Wed, Apr 20, 2016 at 11:11 PM Jonas Ådahl <jad...@gmail.com> wrote:

> If the version of the source object is old enough to not have
> wl_data_source.set_actions() the current action would never be updated
> since source->set_actions would never be set.
>
> To fix this, instead of checking whether source->set_actions before
> proceeding with updating the current action, just always update the
> action when we know all parts are valid dnd data device objects.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  src/data-device.c | 22 --
>  1 file changed, 12 insertions(+), 10 deletions(-)
>
> diff --git a/src/data-device.c b/src/data-device.c
> index 862a4e0..f04f030 100644
> --- a/src/data-device.c
> +++ b/src/data-device.c
> @@ -160,7 +160,7 @@ data_offer_update_action(struct weston_data_offer
> *offer)
>  {
> uint32_t action;
>
> -   if (!offer->source || !offer->source->actions_set)
> +   if (!offer->source)
> return;
>
> action = data_offer_choose_action(offer);
> @@ -293,7 +293,7 @@ destroy_offer_data_source(struct wl_listener
> *listener, void *data)
> offer->source = NULL;
>  }
>
> -static struct wl_resource *
> +static struct weston_data_offer *
>  weston_data_source_send_offer(struct weston_data_source *source,
>   struct wl_resource *target)
>  {
> @@ -331,9 +331,8 @@ weston_data_source_send_offer(struct
> weston_data_source *source,
>
> source->offer = offer;
> source->accepted = false;
> -   data_offer_update_action(offer);
>
> -   return offer->resource;
> +   return offer;
>  }
>
>  static void
> @@ -533,11 +532,13 @@ weston_drag_set_focus(struct weston_drag *drag,
>
> if (drag->data_source) {
> drag->data_source->accepted = false;
> -   offer_resource =
> weston_data_source_send_offer(drag->data_source,
> -  resource);
> -   if (offer_resource == NULL)
> +   offer = weston_data_source_send_offer(drag->data_source,
> resource);
> +   if (offer == NULL)
> return;
>
> +   data_offer_update_action(offer);
> +
> +   offer_resource = offer->resource;
> if (wl_resource_get_version (offer_resource) >=
> WL_DATA_OFFER_SOURCE_ACTIONS_SINCE_VERSION) {
> wl_data_offer_send_source_actions (offer_resource,
> @@ -1095,7 +1096,8 @@ destroy_selection_data_source(struct wl_listener
> *listener, void *data)
>  WL_EXPORT void
>  weston_seat_send_selection(struct weston_seat *seat, struct wl_client
> *client)
>  {
> -   struct wl_resource *data_device, *offer;
> +   struct weston_data_offer *offer;
> +   struct wl_resource *data_device;
>
> wl_resource_for_each(data_device, >drag_resource_list) {
> if (wl_resource_get_client(data_device) != client)
> @@ -1103,8 +1105,8 @@ weston_seat_send_selection(struct weston_seat *seat,
> struct wl_client *client)
>
> if (seat->selection_data_source) {
> offer =
> weston_data_source_send_offer(seat->selection_data_source,
> -
>  data_device);
> -   wl_data_device_send_selection(data_device, offer);
> + data_device);
>


Trying to mix in whitespace changes to throw off your reviewers is
certainly a valid strategy.



> +   wl_data_device_send_selection(data_device,
> offer->resource);
> } else {
> wl_data_device_send_selection(data_device, NULL);
> }
> --
> 2.5.5
>
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel


Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH weston 4/4] input: Don't try to send axis_source when there are no resources

[Mike Blumenkrantz]

Functionally Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com> but the
commit message is a bit confusing

On Wed, Apr 20, 2016 at 11:11 PM Jonas Ådahl <jad...@gmail.com> wrote:

> We miss to NULL check the focus_client, which is only non-NULL when
> there the focused client has any resources.
>
> https://bugs.freedesktop.org/show_bug.cgi?id=94899
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  src/input.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/src/input.c b/src/input.c
> index c881792..8fe898c 100644
> --- a/src/input.c
> +++ b/src/input.c
> @@ -367,6 +367,9 @@ weston_pointer_send_axis_source(struct weston_pointer
> *pointer, uint32_t source)
> struct wl_resource *resource;
> struct wl_list *resource_list;
>
> +   if (!pointer->focus_client)
> +   return;
> +
> resource_list = >focus_client->pointer_resources;
> wl_resource_for_each(resource, resource_list) {
> if (wl_resource_get_version(resource) >=
> --
> 2.5.5
>
> ___
> 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

Re: [PATCH weston 2/4] desktop-shell: Get rid of some unused fields

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Wed, Apr 20, 2016 at 11:11 PM Jonas Ådahl <jad...@gmail.com> wrote:

> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  desktop-shell/shell.c | 6 --
>  1 file changed, 6 deletions(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index f705c99..cd269a8 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -124,9 +124,7 @@ struct shell_surface {
> enum shell_surface_type type;
> char *title, *class;
> int32_t saved_x, saved_y;
> -   int32_t saved_width, saved_height;
> bool saved_position_valid;
> -   bool saved_size_valid;
> bool saved_rotation_valid;
> int unresponsive, grabbed;
> uint32_t resize_edges;
> @@ -2704,9 +2702,6 @@ set_full_output(struct shell_surface *shsurf)
>  {
> shsurf->saved_x = shsurf->view->geometry.x;
> shsurf->saved_y = shsurf->view->geometry.y;
> -   shsurf->saved_width = shsurf->surface->width;
> -   shsurf->saved_height = shsurf->surface->height;
> -   shsurf->saved_size_valid = true;
> shsurf->saved_position_valid = true;
>
> if (!wl_list_empty(>rotation.transform.link)) {
> @@ -3705,7 +3700,6 @@ create_common_surface(struct shell_client *owner,
> void *shell,
> shsurf->shell = (struct desktop_shell *) shell;
> shsurf->unresponsive = 0;
> shsurf->saved_position_valid = false;
> -   shsurf->saved_size_valid = false;
> shsurf->saved_rotation_valid = false;
> shsurf->surface = surface;
> shsurf->fullscreen.type =
> WL_SHELL_SURFACE_FULLSCREEN_METHOD_DEFAULT;
> --
> 2.5.5
>
> ___
> 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

Re: [PATCH weston 1/4] desktop-shell: Unset the shell surface owner when it goes away

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Wed, Apr 20, 2016 at 11:11 PM Jonas Ådahl <jad...@gmail.com> wrote:

> On client destruction, the shell object may be destroyed before the
> shell surface objects. If this happens to two surfaces of the same
> client, and one surface being destroyed results in the focus being
> switched to the other, this would trigger a ping event.
>
> The ping event sending function relies on having a valid owner, and if
> the shell would be destoryed prior to the shell surface, we'd crash in
> this function.
>
> Solve this by unsetting the owner pointer when the shell client goes
> away and early out in the ping event sending function if the owner is
> gone.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  desktop-shell/shell.c | 11 ++-
>  1 file changed, 10 insertions(+), 1 deletion(-)
>
> diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> index 24437d8..f705c99 100644
> --- a/desktop-shell/shell.c
> +++ b/desktop-shell/shell.c
> @@ -2149,6 +2149,8 @@ ping_handler(struct weston_surface *surface,
> uint32_t serial)
> return;
> if (shsurf->surface == shsurf->shell->grab_surface)
> return;
> +   if (!shsurf->owner)
> +   return;
>
> handle_xdg_ping(shsurf, serial);
>  }
> @@ -3778,7 +3780,8 @@ shell_get_shell_surface(struct wl_client *client,
> wl_resource_set_implementation(shsurf->resource,
>_surface_implementation,
>shsurf,
> shell_destroy_shell_surface);
> -   wl_list_init(wl_resource_get_link(shsurf->resource));
> +   wl_list_insert(>surface_list,
> +  wl_resource_get_link(shsurf->resource));
>  }
>
>  static bool
> @@ -5864,6 +5867,8 @@ handle_shell_client_destroy(struct wl_listener
> *listener, void *data)
>  {
> struct shell_client *sc =
> container_of(listener, struct shell_client,
> destroy_listener);
> +   struct wl_resource *shsurf_resource;
> +   struct shell_surface *shsurf;
>
> if (sc->ping_timer)
> wl_event_source_remove(sc->ping_timer);
> @@ -5872,6 +5877,10 @@ handle_shell_client_destroy(struct wl_listener
> *listener, void *data)
>  * head of the surface list so we don't use that freed list node
>  * during surface clean up later on.
>  */
> +   wl_resource_for_each(shsurf_resource, >surface_list) {
> +   shsurf = wl_resource_get_user_data(shsurf_resource);
> +   shsurf->owner = NULL;
> +   }
> wl_list_remove(>surface_list);
>
> free(sc);
> --
> 2.5.5
>
> ___
> 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

Re: [PATCH wayland-protocols 7/7] xdg-shell: Introduce xdg_positioner

[Mike Blumenkrantz]

I've emerged from my bike shed in order to join this expert-level
shedcraftsmanship discussion.

On Thu, Apr 14, 2016 at 4:28 AM Jonas Ådahl <jad...@gmail.com> wrote:

> xdg_positioner is a method for declarative positioning of child surfaces
> (currently only xdg_popup surfaces). A client creates a description of a
> positioning logic using the xdg_positioner interface. The xdg_positioner
> object is then used when creating a xdg_popup for describing how the
> child surface should be positioned in relation to the parent surface.
>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> Signed-off-by: Mike Blumenkrantz <zm...@samsung.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 206
> ++-
>  1 file changed, 204 insertions(+), 2 deletions(-)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index a2a6f12..2b51802 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -57,6 +57,15 @@
>
>  
>
> +
> +  
> +   Create a positioner object. A positioner object is used to position
> +   surfaces relative to some parent surface. See the interface
> description
>

If this is going to operate based on a surface's parent (ie. set_parent)
then it should read "A position object is used to position its surface(s)
relative to their parent surface (see set_parent)" in order to avoid any
confusion.

Moreover, I'm thinking this object needs to somehow be tethered to a single
toplevel hierarchy; the current text has no restrictions about the
positioner's use, meaning that it could be used for eg.

Surface A
[Positioner P]
Popup A

Surface B
[Positioner P]
Popup B
[Positioner P]
Popup B2

which would be confusing, and could also lead to annoying calculation
issues if Surface A was huge and Surface B was tiny.


> +   for details.
> +  
> +  
> +
> +
>  
>
> This creates an xdg_surface for the given surface. While
> xdg_surface
> @@ -96,6 +105,186 @@
>  
>
>
> +  
> +
> +  The xdg_positioner provides an interface for constructing
> positioning
> +  rules used for positioning a child surface relative to another
> surface
>

Same as above.


> +  in a certain way. It allows methods for defining a rule that will
> make
> +  the child surface stay within the border of the visible area of the
>

I'd rather have this specifically reference "the positioner's surface(s)"
or similar instead of "the child surface" in order to keep context within
the positioner interface.


> +  screen, with different ways in which the child surface should change
> +  its position, including sliding along an axis, or flipping around a
> +  rectangle.
> +
> +  See the various requests for details about possible rules.
> +
> +  An xdg_positioner object may be re-used when positioning different
>

Saying "re-used" here makes it sound like the positioner can only have one
surface attached to it at a time. I think something like "...may continue
to be applied to any xdg_popup surfaces until destroyed..." would be more
clear.


> +  surfaces until destroyed using xdg_positioner.destroy.
> +
> +
> +
> +  
> +
> +
> +
> +  
> +   Notify the compositor that the xdg_positioner will no longer be
> used.
>

Should this include an explicit note about what to do with surfaces which
were using the positioner, eg. "No changes should be made to users of the
positioner upon its destruction" ?


> +  
> +
> +
> +
> +  
>

"set the anchor rectangle within the parent surface"


> +   Specify the anchor rectangle of the parent surface that the child
> +   surface will be placed relative to. The rectangle is relative to
> the
> +   window geometry as defined by xdg_surface.set_window_geometry of
> the
> +   parent surface. The rectangle must be at least be 1x1 large.
> +
> +   When used to position a child surface, the attach rectangle may not
> +   extend outside of the window geometry of the parent surface.
>

I think this also needs to be clarified to something like "The positioner's
attach rectangle may not extend outside the window geometry of the user
surface's parent" in order to handle the case where the positioner is used
for multiple surfaces with different parents in the same hierarchy chain
(assuming this is going to be allowed).


> +  
> +  
> +  
> +  
> +  
> +
> +
> +
> +   +summary=&quo

Re: [PATCH v6 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Reviewed-By: Mike Blumenkrantz <zm...@osg.samsung.com>

On Wed, Apr 13, 2016 at 2:18 PM Olivier Fourdan <ofour...@redhat.com> wrote:

> Just a quick note, not that it matters much, but this should have been v7,
> not v6, I got confused with the numbering of iterations :)
>
> Cheers,
> Olivier
>
> - Original Message -
> > Some application may wish to restrict their window in size, but
> > xdg-shell has no mechanism for the client to specify a maximum or
> > minimum size.
> >
> > As a result, the compositor may try to maximize or fullscreen a window
> > while the client would not allow for the requested size.
> >
> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> > the client can tell the compositor what would be its smallest/largest
> > acceptable size, and that the compositor can decide if maximize or
> > fullscreen is achievable, draw an accurate animation, etc.
> >
> > Signed-off-by: Olivier Fourdan <ofour...@redhat.com>
> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> > ---
> >  v2: Rename the request to "set_preferred_max_size",
> >  add "set_preferred_min_size" as well
> >  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> >  Rephrase description to clarify the unscaled size and using 0 to
> >  reset back the preferred size to an unspecified state
> >  v4: Patch the correct xml file (v6, not v5 )
> >  Fix multiple mismatch of min/max in the description
> >  Remove mention of "unscaled", specify window geometry coordinates
> >  and refer to set_window_geometry.
> >  v5: Fix typos and remove "preferred" from the name and description as
> >  requested by several people on the ML and irc.
> >  v6: Specify the requests are double-buffered and require a commit,
> >  rephrase the values never set as suggested by Jasper, state
> >  that min > max is an invalid state and result in a protocol error
> >  as suggested by Bill, Yong and Jonas.
> >  Specify that width/height values must be greater than or equal to
> >  zero as discussed with Mike.
> >
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74
> >  
> >  1 file changed, 74 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 3fc7d42..eba31ce 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -489,6 +489,80 @@
> >
> >  
> >
> > +
> > +  
> > + Set a maximum size for the window.
> > +
> > + The client can specify a maximum size so that the compositor does
> > + not try to configure the window beyond this size.
> > +
> > + The width and height arguments are in window geometry coordinates.
> > + See set_window_geometry.
> > +
> > + Values set in this way are double-buffered. They will get applied
> > + on the next commit.
> > +
> > + The compositor can use this information to allow or disallow
> > + different states like maximize or fullscreen and draw accurate
> > + animations.
> > +
> > + Similarly, a tiling window manager may use this information to
> > + place and resize client windows in a more effective way.
> > +
> > + If never set, or a value of zero in the request, means that the
> > + client has no expected maximum size in the given dimension.
> > + As a result, a client wishing to reset the maximum size
> > + to an unspecified state can use zero for width and height in the
> > + request.
> > +
> > + Requesting a maximum size to be smaller than the minimum size of
> > + a surface is illegal and will result in a protocol error.
> > +
> > + The width and height must be greater than or equal to zero. Using
> > + strictly negative values for width and height will result in a
> > + protocol error.
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > + Set a minimum size for the window.
> > +
> > + The client can specify a minimum size so that the compositor does
> > + not try to configure the window below this size.
> > +
> > + The width and height arguments are in window geometry coordinates.
> > + See set_window_geometry.
> > +
> > + Values set

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Sure, that sounds good to me!

On Tue, Apr 12, 2016 at 11:24 AM Olivier Fourdan 
wrote:

> Hi Mike.
>
> > Okay, if we're not going with uints then at the least can the "use 0 to
> > unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
> > cover that case?
>
> I think we should simply indicate that the width and height must be
> greater than or equal to zero, so we remain consistent with the other
> descriptions (namely set_window_geometry).
>
> Then we could also state that using strictly negative values would raise a
> protocol error?
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

Okay, if we're not going with uints then at the least can the "use 0 to
unset min/max" be changed to "use <= 0 to unset min/max" to explicitly
cover that case?

On Tue, Apr 12, 2016 at 10:40 AM Olivier Fourdan 
wrote:

> Hi,
>
>
> > > Good point. Setting an invalid state should probably result in a
> > > protocol error.
> >
> > No this cannot be a protocol error because that makes it difficult to
> > change the size range to a new one that does not intersect the old one.
> >
> > Perhaps having the commit of an invalid state be a protocol error is ok.
>
> We'd reach an invalid state only once it's applied, ie after the commit.
>
> So the client can (and must) set a Min <= Max before the commit, otherwise
> it's an invalid state that will lead to a protocol error.
>
> That's what I've tried to specify in v6:
>
> Values set in this way are double-buffered. They will get applied
> on the next commit.
>
> [...]
>
> Requesting a minimum size to be larger than the maximum size of
> a surface is illegal and will result in a protocol error.
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH v5 xdg-shell-unstable-v6] xdg-shell: Add min/max size requests

[Mike Blumenkrantz]

I think this should probably use uint instead of int for params since zero
is the "unset" number. Otherwise you have to write something about negative
sizes.

On Mon, Apr 11, 2016 at 3:11 PM Jasper St. Pierre 
wrote:

> On Mon, Apr 11, 2016 at 12:59 AM, Olivier Fourdan 
> wrote:
> > Some application may wish to restrict their window in size, but
> > xdg-shell has no mechanism for the client to specify a maximum or
> > minimum size.
> >
> > As a result, the compositor may try to maximize or fullscreen a window
> > while the client would not allow for the requested size.
> >
> > Add new requests "set_max_size" and "set_min_size" to xdg-shell so that
> > the client can tell the compositor what would be its smallest/largest
> > acceptable size, and that the compositor can decide if maximize or
> > fullscreen is achievable, draw an accurate animation, etc.
> >
> > Signed-off-by: Olivier Fourdan 
> > Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> > ---
> >  v2: Rename the request to "set_preferred_max_size",
> >  add "set_preferred_min_size" as well
> >  v3: Rebase above patch 72427 in branch xdg-shell-unstable-v6
> >  Rephrase description to clarify the unscaled size and using 0 to
> >  reset back the preferred size to an unspecified state
> >  v4: Patch the correct xml file (v6, not v5 )
> >  Fix multiple mismatch of min/max in the description
> >  Remove mention of "unscaled", specify window geometry coordinates
> >  and refer to set_window_geometry.
> >  v5: Fix typos and remove "preferred" from the name and description as
> >  requested by several people on the ML and irc.
> >
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 60
> 
> >  1 file changed, 60 insertions(+)
> >
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 3fc7d42..8ab84f5 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -489,6 +489,66 @@
> >
> >  
> >
> > +
> > +  
> > +   Set a maximum size for the window.
> > +
> > +   The client can specify a maximum size so that the compositor does
> > +   not try to configure the window beyond this size.
> > +
> > +   The width and height arguments are in window geometry
> coordinates.
> > +   See set_window_geometry.
> > +
> > +   The compositor can use this information to allow or disallow
> > +   different states like maximize or fullscreen and draw accurate
> > +   animations.
> > +
> > +   Similarly, a tiling window manager may use this information to
> > +   place and resize client windows in a more effective way.
> > +
> > +   If never set, the maximum size of the window is not limited by
> > +   the client.
>
> Delete this sentence, and merge it into the paragraph below.
>
> > +   A value of zero in the request for either width, height or both
> > +   means that the client has no expected maximum size in the given
> > +   dimension. As a result, a client wishing to reset the maximum
> size
> > +   to an unspecified state can use zero for width and height in the
> > +   request.
>
> If never set, or a value of zero in the request, means that the client
> has no expected...
>
> > +  
> > +  
> > +  
> > +
> > +
> > +
> > +  
> > +   Set a minimum size for the window.
> > +
> > +   The client can specify a minimum size so that the compositor does
> > +   not try to configure the window below this size.
> > +
> > +   The width and height arguments are in window geometry
> coordinates.
> > +   See set_window_geometry.
> > +
> > +   The compositor can use this information to allow or disallow
> > +   different states like maximize or fullscreen and draw accurate
> > +   animations.
> > +
> > +   Similarly, a tiling window manager may use this information to
> > +   place and resize client windows in a more effective way.
> > +
> > +   If never set, the minimum size of the window is not limited by
> > +   the client.
> > +
> > +   A value of zero in the request for either width, height or both
> > +   means that the client has no expected minimum size in the given
> > +   dimension. As a result, a client wishing to reset the minimum
> size
> > +   to an unspecified state can use zero for width and height in the
> > +   request.
> > +  
> > +  
> > +  
> > +
> > +
> >  
> >
> > Maximize the surface.
> > --
> > 2.5.5
> >
>
>
>
> --
>   Jasper
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
___
wayland-devel mailing list

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

On Mon, Apr 4, 2016 at 3:30 PM Olivier Fourdan  wrote:

>
> Hi Mike,
>
> - Original Message -
> > [...]
> >
> > Yes, I know you are not currently advocating for it, but you've proved my
> > point--others will see this go in and then they will push for it. Adding
> > any form of size hints is a slipper slope which leads to more size hints
> > imo.
>
> My turn to play the Devil's advocate then :-)
>
> And even if we end with more hints eventually, what is wrong with that?
>
> I reckon if we had hints in X11, it's also because people have had a need
> for such a mechanism...
>
> Cheers,
> Olivier
>

Sure, and as I said, I have no issues with that if a separate (optional)
protocol  is created for it. I just don't think that the best place for it
is in xdg-shell, which is supposed to be just a small core set of features
that are absolutely required in order to create a usable desktop
environment.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

On Mon, Apr 4, 2016 at 1:17 PM Olivier Fourdan  wrote:

> Hi Mike,
>
> > Hm, you raise some interesting points. However, I think your argument is
> > somewhat misled by your claim that "this case is unique". If there is an
> > application which does not want to be larger than a certain size, why
> could
> > there not also be an application which does not want to be smaller than a
> > certain size?
>
> It's unique because switching to maximize/fullscreen is not an interactive
> resize, ie the client doesn't have its word on the state change that
> implies the resize, and is mandatory configure event, until it's set by the
> compositor (ie too late, the client must obey, period).
>

Maximize can mean different things in different cases. For example, suppose
a compositor has a maximize policy where it can "maximize" a window to take
up the top-left 25% of the screen. This size could be too small for the
application, yet it falls within your non-interactive resize case.


>
> > It seems like continuing to add size hints based on this logic is almost
> > guaranteed, especially if you then add in the point of tiling
> > policies--surely handling tiling would be made even easier by adding
> > min/step/aspect sizes!
> >
> > To me, xdg-shell should just be a bare minimum of things required to
> > implement a UI with Wayland. Perhaps if there's a real need for size
> hints
> > (which I really hope there isn't, since it made X11 window sizing very
> > annoying) then there should be a separate size hints protocol where all
> of
> > this can be implemented?
>
> One case where a compositor may need a min size hint is a tiling
> window/compositing manager, so it can base its heuristics on those hints
> from the clients to get the optimal window size for tiling, but I would let
> those who implement such a window/compositor manager advocate for that,
> it's not the specific case I'm interested in here :-)
>
> Cheers,
> Olivier
>

Yes, I know you are not currently advocating for it, but you've proved my
point--others will see this go in and then they will push for it. Adding
any form of size hints is a slipper slope which leads to more size hints
imo.
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

Hm, you raise some interesting points. However, I think your argument is
somewhat misled by your claim that "this case is unique". If there is an
application which does not want to be larger than a certain size, why could
there not also be an application which does not want to be smaller than a
certain size?

It seems like continuing to add size hints based on this logic is almost
guaranteed, especially if you then add in the point of tiling
policies--surely handling tiling would be made even easier by adding
min/step/aspect sizes!

To me, xdg-shell should just be a bare minimum of things required to
implement a UI with Wayland. Perhaps if there's a real need for size hints
(which I really hope there isn't, since it made X11 window sizing very
annoying) then there should be a separate size hints protocol where all of
this can be implemented?

On Mon, Apr 4, 2016 at 12:55 PM Olivier Fourdan  wrote:

> Hi Mike,
>
> Thanks for starting the discussion! :)
>
> - Original Message -
> > Just to play devil's advocate, do we really want to start getting into
> size
> > hint type stuff? After this will be min size, then step size, then
> aspect,
> > ...
>
> I think these are different issues.
>
> min size, step size, aspect are client specific, you usually don't find a
> compositor that lets you non-interactively resize a window to arbitrary
> size, the only exception for that is maximize and fullscreen.
>
> This is really needed solely to let the compositor know what would be the
> largest acceptable size for the given surface (as for interactive resize,
> the client has the final word so we do have size increment, min size, even
> aspect ratio covered).
>
> I have been rightfully pointed out that the gnome bug where I started from
> is actually an application bug, ie xdg-shell clearly states that if the
> surface is maximized or fullscreen, the window geometry specified in the
> configure event must be obeyed by the client, so I have attached a patch
> for gtk+ to address that.
>
> Yet, I think a way for the client to let the compositor know that its
> surface should not be resized to anything bigger that a given size would
> help improve the user experience, not all windows look good when resized to
> arbitrary large sizes (they can doesn't necessarily mean they should).
>
> Beside, as opposed to what was stated on irc, I think it would also help
> with tiling window managers as well, to base their euristic on the largest
> optimal size for some windows.
>
> Cheers,
> Olivier
>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH] xdg-shell: add set_max_size request

[Mike Blumenkrantz]

Just to play devil's advocate, do we really want to start getting into size
hint type stuff? After this will be min size, then step size, then aspect,
...

On Mon, Apr 4, 2016 at 5:14 AM Olivier Fourdan  wrote:

> Some application may wish to restrict their window in size, but
> xdg-shell has no mecanism for the client to advertise such a maximimum
> size.
>
> As a result, the compositor may try to maximize or fullscreen a window
> while the client would not allow for the requested size.
>
> Add a new request "set_max_size" to xdg-shell so that the client can
> tell the compositor which would be its largest acceptable size, so that
> the compositor can decide if maximize or fullscreen makes sense, draw
> an accurate animation, etc.
>
> Signed-off-by: Olivier Fourdan 
> Bugzilla: https://bugzilla.gnome.org/show_bug.cgi?id=764413
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 20 
>  1 file changed, 20 insertions(+)
>
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> index 542491f..e9e0f1d 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> @@ -462,6 +462,26 @@
>
>  
>
> +
> +  
> +The client can set a maximum size to tell the compositor what
> would
> +be the largest acceptable size of a surface.
> +
> +The compositor can use this information to allow or disallow the
> +maximized or fullscreen state depending on the actual output size
> +for example, or draw a more accurate animation when transitionning
> +states.
> +
> +If never set, the size is not limited by the client.
> +
> +A value of zero for either width, height or both means that the
> +size is not limited for the given dimension.
> +  
> +  
> +  
> +
> +
> +
>  
>
>  Maximize the surface.
> --
> 2.5.5
>
> ___
> 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

Re: [PATCH wayland-protocols] unstable: Add the Wayland Wobbly Windows protocol

[Mike Blumenkrantz]

Thanks for this detailed and thorough review. I will spend some time to
carefully address your comments and follow with a revised version for you
to personally inspect.

On Fri, Apr 1, 2016 at 12:19 PM Daniel Stone  wrote:

> Hi,
>
> On 1 April 2016 at 16:14, Derek Foreman  wrote:
> > diff --git a/unstable/www/www-unstable-v1.xml
> b/unstable/www/www-unstable-v1.xml
> > new file mode 100644
> > index 000..cb928a9
> > --- /dev/null
> > +++ b/unstable/www/www-unstable-v1.xml
> > @@ -0,0 +1,58 @@
> > +
> > +
> > +
> > +  
> > +Copyright C 2016  Samsung Electronics
>
> It's 2016: we have Unicode copyright codepoints.
>
> > +  
>
> Where did we land on capitalisation rules for protocol elements? I forget.
>
> > +This protocol provides support for wobbly windows on Wayland by
> > +informing a client when it has moved or is being dragged.
> > +  
>
> Doesn't the client know it's being dragged most of the time anyway,
> due to wl_shell::drag and friends?
>
> > +  
> > +
> > +  
> > +  
> > +  
> > +  
> > +
> > +  
>
> These are not great descriptions, honestly. Is the surface required to
> have a particular role (e.g. toplevel)?
>
> > +  
> > +
> > +   
>
> This could be better described, since it's relative input. Is it
> unaccelerated?
>
> > +   
> > +   
>
> Not fixed? :(
>
> > +   
>
> What units does the timestamp use? What about reusing the
> relative-pointer from Jonas?
>
> > +
> > +   
> > +
> > +
> > +   
> > +
>
> You may want to make it clear here that this does not relate to drag &
> drop.
>
> > +
> > +  
> > +  
> > +
>
> The parent interface lacks a destructor as well.
>
> Overall, 2/10. See me after class.
>
> Cheers,
> Daniel
> ___
> 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

Re: [RFC wayland 10/18] scanner: Add the concept of "pre hooks"

[Mike Blumenkrantz]

On Tue, 09 Feb 2016 10:55:57 -0600
Derek Foreman  wrote:

> A pre hook is a wayland library call made on the client side before the
> request is sent.
> 
> Until now the wayland library has simply passed requests on without any
> knowledge of what they mean, and the receiving compositor has all the
> logic.  For network transparency to be truly transparent, the library
> needs to intercept some things on the client side (buffer set-up, damage
> posting) and send along additional information.
> 
> pre-hooks make that possible.
> 
> Signed-off-by: Derek Foreman 
> ---
>  protocol/wayland.dtd  |   1 +
>  src/scanner.c | 108 
> +++---
>  src/wayland-client-core.h |  10 +
>  src/wayland-client.c  |  13 ++
>  4 files changed, 126 insertions(+), 6 deletions(-)
> 
> diff --git a/protocol/wayland.dtd b/protocol/wayland.dtd
> index 15f20ab..15ca9cc 100644
> --- a/protocol/wayland.dtd
> +++ b/protocol/wayland.dtd
> @@ -8,6 +8,7 @@
>
>
>
> +  
>  
>
>
> diff --git a/src/scanner.c b/src/scanner.c
> index 9a74e93..e598200 100644
> --- a/src/scanner.c
> +++ b/src/scanner.c
> @@ -170,6 +170,7 @@ struct message {
>   int destructor;
>   int since;
>   struct description *description;
> + bool hooked;
>  };
>  
>  enum arg_type {
> @@ -609,6 +610,7 @@ start_element(void *data, const char *element_name, const 
> char **atts)
>   const char *allow_null = NULL;
>   const char *enumeration_name = NULL;
>   const char *bitfield = NULL;
> + const char *hooked = NULL;
>   int i, version = 0;
>  
>   ctx->loc.line_number = XML_GetCurrentLineNumber(ctx->parser);
> @@ -636,6 +638,8 @@ start_element(void *data, const char *element_name, const 
> char **atts)
>   enumeration_name = atts[i + 1];
>   if (strcmp(atts[i], "bitfield") == 0)
>   bitfield = atts[i + 1];
> + if (strcmp(atts[i], "hooked") == 0)
> + hooked = atts[i + 1];
>   }
>  
>   ctx->character_data_length = 0;
> @@ -665,6 +669,15 @@ start_element(void *data, const char *element_name, 
> const char **atts)
>  
>   message = create_message(ctx->loc, name);
>  
> + if (hooked) {
> + if (strcmp(hooked, "true") == 0)
> + message->hooked = true;
> + else if (strcmp(hooked, "false") != 0)
> + fail(>loc,
> +  "invalid value for hooked attribute (%s)",
> +  hooked);
> + }
> +
>   if (strcmp(element_name, "request") == 0)
>   wl_list_insert(ctx->interface->request_list.prev,
>  >link);
> @@ -938,6 +951,79 @@ emit_type(struct arg *a)
>  }
>  
>  static void
> +emit_pre_hook_prototype(struct message *m, struct interface *interface, 
> struct arg *r)
> +{
> + struct arg *a;
> +
> + if (r)
> + printf("void *\n");
> + else
> + printf("void\n");
> +
> + printf("%s_%s_pre_hook(struct %s *",
> +interface->name, m->name, interface->name);
> + wl_list_for_each(a, >arg_list, link) {
> + if (a->type == NEW_ID && a->interface_name == NULL) {
> + printf(", const struct wl_interface *interface"
> +", uint32_t version");
> + continue;
> + } else if (a->type == NEW_ID)
> + continue;
> + printf(", ");
> + emit_type(a);
> + printf("%s", a->name);
> + }
> + printf(");");
> +}
> +
> +static void
> +emit_pre_hooks(struct wl_list *message_list, struct interface *interface)
> +{
> + struct message *m;
> + int hooks = 0;
> +
> + if (wl_list_empty(message_list))
> + return;
> + wl_list_for_each(m, message_list, link) {
> + struct arg *a, *ret = NULL;
> +
> + if (!m->hooked)
> + continue;
> +
> + wl_list_for_each(a, >arg_list, link) {
> + if (a->type == NEW_ID)
> + ret = a;
> + }
> +
> + emit_pre_hook_prototype(m, interface, ret);
> + hooks++;
> + }
> + if (hooks)
> + printf("\n");
> +}
> +
> +static void emit_call_pre_hook(struct interface *interface, struct arg *ret, 
> struct message *m)
> +{
> + struct arg *a;
> +
> + if (ret) {
> + printf("\tvoid *hook_data = %s_%s_pre_hook(%s", 
> interface->name, m->name, interface->name);
> + } else
> + printf("\t%s_%s_pre_hook(%s", interface->name, m->name, 
> interface->name);
> + wl_list_for_each(a, >arg_list, link) {
> + if (a->type == NEW_ID && a->interface_name == NULL) {
> + 

Re: Moving bugs to Phabricator

[Mike Blumenkrantz]

Hi,

It seems that opening any of these links requires a login. A valid use case for 
bug trackers is something like:

* user searches web for issue keywords (eg. "wayland has no ssd!")
* results include link to bug
* user views bug report

Requiring a login will create more hassle and reduce the likelihood that 
tickets will be seen.

For reference, we switched to phabricator a few years ago for EFL and had this 
exact issue. Some parts of the site can be made public, but the majority of it 
seems to be locked down and only accessible to logged-in users.

On Wed, 03 Feb 2016 12:25:26 +
Daniel Stone  wrote:

> Hi,
> 
> On 2 February 2016 at 20:28, Bill Spitzak  wrote:
> > Can you make a clone of the current Bugzilla state in Phabricator so that we
> > can see what it looks like?  
> 
> Good idea! Here they are:
> https://phabricator.freedesktop.org/project/board/100/
> https://phabricator.freedesktop.org/project/board/101/
> https://phabricator.freedesktop.org/project/board/102/
> https://phabricator.freedesktop.org/project/board/103/
> 
> Please bear in mind these are REAL IMPORTED BUGS linked to REAL ACTUAL
> PEOPLE. Manipulating these tasks will lead to actual people being
> emailed, just as it would on Bugzilla. But please feel free to mess
> around with your own bugs, or create new ones and play with those.
> 
> The workboard columns aren't fixed in the current single-column
> format: depending on what works best, we could use any combination of
> one column per release, status-based columns (WIP / mid-bikeshed /
> etc), or anything really.
> 
> Also, you can make more general (and more advanced) queries from
> https://phabricator.freedesktop.org/maniphest/.
> 
> Would be interested to hear some more feedback from people!
> 
> Cheers,
> Daniel
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Mike Blumenkrantz]

On Sun, 17 Jan 2016 10:37:09 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> On Sat, Jan 16, 2016 at 03:07:00PM -0500, Mike Blumenkrantz wrote:
> > On Sat, 16 Jan 2016 10:28:20 +0800
> > Jonas Ådahl <jad...@gmail.com> wrote:
> >   
> > > On Fri, Jan 15, 2016 at 09:19:34PM -0500, Mike Blumenkrantz wrote:  
> > > > Hi,
> > > > 
> > > > I have some suggestions which I've inlined below:
> > > > 
> > > > On Tue, 12 Jan 2016 16:16:49 +0800
> > > > Jonas Ådahl <jad...@gmail.com> wrote:
> > > > 
> > > > > An xdg_tooltip is a new window type used to implement tooltip like
> > > > > surfaces. See the interface documentation for details.
> > > > > 
> > > > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > > > > ---
> > > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> > > > > 
> > > > >  1 file changed, 47 insertions(+)
> > > > > 
> > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > index 276d9fc..91f657a 100644
> > > > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > @@ -183,6 +183,23 @@
> > > > >
> > > > >  
> > > > >  
> > > > > +
> > > > > +  
> > > > > + This creates an xdg_tooltip for the given xdg_surface and gives 
> > > > > the
> > > > > + associated wl_surface the xdg_tooltip role. A wl_surface can 
> > > > > only have
> > > > > + one xdg_tooltip role. If the wl_surface is given the 
> > > > > xdg_tooltip role
> > > > > + while it already has an active xdg_tooltip role, or if it has 
> > > > > been given
> > > > > + any other role before, an error is raised.
> > > > 
> > > > I think my comment on the first patch proves its relevance here as this 
> > > > section could
> > > > be greatly shortened by specifying singular surface role semantics in 
> > > > xdg_surface.
> > > > 
> > > > > +
> > > > > + See the documentation of xdg_tooltip for more details about 
> > > > > what an
> > > > > + xdg_tooltip is and how it is used.
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +  
> > > > > +
> > > > > +
> > > > >  
> > > > >
> > > > >   The window geometry of a surface is its "visible bounds" from 
> > > > > the
> > > > > @@ -666,4 +683,34 @@
> > > > >  
> > > > >
> > > > >  
> > > > > +  
> > > > > +
> > > > > +  This interface defines an xdg_tooltip role that provides 
> > > > > functionality
> > > > > +  related to tooltip like surfaces.
> > > > > +
> > > > > +  An xdg_tooltip is temporary a surface that is part of another 
> > > > > xdg_surface
> > > > > +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a 
> > > > > UI widget. It
> > > > > +  will always be mapped above both its parent and if the parent 
> > > > > has a
> > > > > +  xdg_popup child it will also be mapped above that and all 
> > > > > other possible
> > > > > +  chained xdg_popup surfaces.
> > > > 
> > > > "An xdg_tooltip is a temporary surface which is displayed over its 
> > > > parent xdg_surface.
> > > > The last-created xdg_tooltip surface will always be the top-most child 
> > > > of the parent xdg_surface."
> > > > 
> > > > > +
> > > > > +  The parent surface must either have the surface role 
> > > > > xdg_toplevel,
> > > > > +  xdg_popup or xdg_tooltip.
> > > > > +
> > > > > +  Being different from xdg_popup, it does not take an active 
> > > > > grab while
> > > > > +  being mapped, and it will never be autom

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Mike Blumenkrantz]

On Sat, 16 Jan 2016 10:28:20 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> On Fri, Jan 15, 2016 at 09:19:34PM -0500, Mike Blumenkrantz wrote:
> > Hi,
> > 
> > I have some suggestions which I've inlined below:
> > 
> > On Tue, 12 Jan 2016 16:16:49 +0800
> > Jonas Ådahl <jad...@gmail.com> wrote:
> >   
> > > An xdg_tooltip is a new window type used to implement tooltip like
> > > surfaces. See the interface documentation for details.
> > > 
> > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > > ---
> > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> > > 
> > >  1 file changed, 47 insertions(+)
> > > 
> > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > index 276d9fc..91f657a 100644
> > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > @@ -183,6 +183,23 @@
> > >
> > >  
> > >  
> > > +
> > > +  
> > > + This creates an xdg_tooltip for the given xdg_surface and gives the
> > > + associated wl_surface the xdg_tooltip role. A wl_surface can only have
> > > + one xdg_tooltip role. If the wl_surface is given the xdg_tooltip role
> > > + while it already has an active xdg_tooltip role, or if it has been given
> > > + any other role before, an error is raised.  
> > 
> > I think my comment on the first patch proves its relevance here as this 
> > section could
> > be greatly shortened by specifying singular surface role semantics in 
> > xdg_surface.
> >   
> > > +
> > > + See the documentation of xdg_tooltip for more details about what an
> > > + xdg_tooltip is and how it is used.
> > > +  
> > > +  
> > > +  
> > > +  
> > > +  
> > > +
> > > +
> > >  
> > >
> > >   The window geometry of a surface is its "visible bounds" from the
> > > @@ -666,4 +683,34 @@
> > >  
> > >
> > >  
> > > +  
> > > +
> > > +  This interface defines an xdg_tooltip role that provides 
> > > functionality
> > > +  related to tooltip like surfaces.
> > > +
> > > +  An xdg_tooltip is temporary a surface that is part of another 
> > > xdg_surface
> > > +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a UI 
> > > widget. It
> > > +  will always be mapped above both its parent and if the parent has a
> > > +  xdg_popup child it will also be mapped above that and all other 
> > > possible
> > > +  chained xdg_popup surfaces.  
> > 
> > "An xdg_tooltip is a temporary surface which is displayed over its parent 
> > xdg_surface.
> > The last-created xdg_tooltip surface will always be the top-most child of 
> > the parent xdg_surface."
> >   
> > > +
> > > +  The parent surface must either have the surface role xdg_toplevel,
> > > +  xdg_popup or xdg_tooltip.
> > > +
> > > +  Being different from xdg_popup, it does not take an active grab 
> > > while
> > > +  being mapped, and it will never be automatically dismissed by any
> > > +  predefined user interaction. The client must itself unmap it using 
> > > the
> > > +  xdg_tooltip.destroy request.  
> > 
> > Wouldn't it be enough to have
> > 
> > "An xdg_tooltip does not take an active grab while mapped. xdg_tooltip 
> > surfaces are
> > either directly unmapped by clients using the xdg_tooltip.destroy request 
> > or indirectly
> > unmapped when their parent surface is unmapped."
> >   
> > > +
> > > +  An xdg_tooltip can receive input assuming it has an input region.  
> > 
> > "An xdg_tooltip obeys normal input region semantics." or similar ?
> >   
> > > +
> > > +  If for some reason its parent is unmapped, for example if the 
> > > parent is a
> > > +  popup being dismissed, the tooltip will be unmapped as well.  
> > 
> > I think this is now covered a few lines up?  
> 
> Hmm. You mean about "always be made top-most child"? It doesn't make it
> clear what happens if the parent is unmapped though.

I'm not sure exactly what you mean by this. I think stating that a tooltip will 
be
"unmapped when their parent surface is unmapped" is fairly clear, no?

> 
> Other comments makes sense though, will fix.
> 
> 
> Jonas
> 
> >   
> > > +
> > > +
> > > +
> > > +  Unmap the tooltip surface and destroy the object.
> > > +
> > > +  
> > > +
> > >
> >   
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 3/3] xdg-shell: Introduce xdg_tooltip

[Mike Blumenkrantz]

Hi,

I have some suggestions which I've inlined below:

On Tue, 12 Jan 2016 16:16:49 +0800
Jonas Ådahl  wrote:

> An xdg_tooltip is a new window type used to implement tooltip like
> surfaces. See the interface documentation for details.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 47 
> 
>  1 file changed, 47 insertions(+)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 276d9fc..91f657a 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -183,6 +183,23 @@
>
>  
>  
> +
> +  
> + This creates an xdg_tooltip for the given xdg_surface and gives the
> + associated wl_surface the xdg_tooltip role. A wl_surface can only have
> + one xdg_tooltip role. If the wl_surface is given the xdg_tooltip role
> + while it already has an active xdg_tooltip role, or if it has been given
> + any other role before, an error is raised.

I think my comment on the first patch proves its relevance here as this section 
could
be greatly shortened by specifying singular surface role semantics in 
xdg_surface.

> +
> + See the documentation of xdg_tooltip for more details about what an
> + xdg_tooltip is and how it is used.
> +  
> +  
> +  
> +  
> +  
> +
> +
>  
>
>   The window geometry of a surface is its "visible bounds" from the
> @@ -666,4 +683,34 @@
>  
>
>  
> +  
> +
> +  This interface defines an xdg_tooltip role that provides functionality
> +  related to tooltip like surfaces.
> +
> +  An xdg_tooltip is temporary a surface that is part of another 
> xdg_surface
> +  (such as xdg_toplevel or xdg_popup) such as a tooltip above a UI 
> widget. It
> +  will always be mapped above both its parent and if the parent has a
> +  xdg_popup child it will also be mapped above that and all other 
> possible
> +  chained xdg_popup surfaces.

"An xdg_tooltip is a temporary surface which is displayed over its parent 
xdg_surface.
The last-created xdg_tooltip surface will always be the top-most child of the 
parent xdg_surface."

> +
> +  The parent surface must either have the surface role xdg_toplevel,
> +  xdg_popup or xdg_tooltip.
> +
> +  Being different from xdg_popup, it does not take an active grab while
> +  being mapped, and it will never be automatically dismissed by any
> +  predefined user interaction. The client must itself unmap it using the
> +  xdg_tooltip.destroy request.

Wouldn't it be enough to have

"An xdg_tooltip does not take an active grab while mapped. xdg_tooltip surfaces 
are
either directly unmapped by clients using the xdg_tooltip.destroy request or 
indirectly
unmapped when their parent surface is unmapped."

> +
> +  An xdg_tooltip can receive input assuming it has an input region.

"An xdg_tooltip obeys normal input region semantics." or similar ?

> +
> +  If for some reason its parent is unmapped, for example if the parent 
> is a
> +  popup being dismissed, the tooltip will be unmapped as well.

I think this is now covered a few lines up?

> +
> +
> +
> +  Unmap the tooltip surface and destroy the object.
> +
> +  
> +
>  

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 2/3] xdg-shell: Make get_popup take a xdg_surface instead of wl_surface

[Mike Blumenkrantz]

On Tue, 12 Jan 2016 16:16:48 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> The reason for using wl_surface before was that xdg_popup and
> xdg_surface (now xdg_toplevel) had no common interface other than
> wl_surface, but since xdg_surface is now the base interface, lets use
> that.
> 
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index d1c315e..276d9fc 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -176,7 +176,7 @@
>   xdg_popup is and how it is used.
>
>
> -  
> +  
>
>
>

Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols 1/3] xdg-shell: Turn xdg_surface into a generic base interface

[Mike Blumenkrantz]

Hi,

I have some suggestions which I've inlined below:

On Tue, 12 Jan 2016 16:16:47 +0800
Jonas Ådahl  wrote:

> Split out toplevel window like requests and events into a new interface
> called xdg_toplevel, and turn xdg_surface into a generic base interface
> which others extends.
> 
> xdg_popup is changed to extend the xdg_surface.
> 
> The configure event in xdg_surface was split up making
> xdg_surface.configure an event only carrying the serial number, while a
> new xdg_toplevel.configure event carries the other data previously sent
> via xdg_surface.configure. xdg_toplevel.configure is made to extend,
> via the latch-state mechanism, xdg_surface.configure and depends on
> that event to synchronize state.
> 
> Other future xdg_surface based extensions are meant to also extend
> xdg_surface.configure for relevant window type dependend state
> synchronization.
> 
> Signed-off-by: Jonas Ådahl 
> ---
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 229 
> +--
>  1 file changed, 148 insertions(+), 81 deletions(-)
> 
> diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> index 2b028c0..d1c315e 100644
> --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -54,11 +54,9 @@
>  
>  
>
> - This creates an xdg_surface for the given surface and gives it the
> - xdg_surface role. A wl_surface can only be given an xdg_surface role
> - once. If get_xdg_surface is called with a wl_surface that already has
> - an active xdg_surface associated with it, or if it had any other role,
> - an error is raised.
> + This creates an xdg_surface for the given surface. While xdg_surface
> + itself is not a role, the corresponding surface may only be assigned
> + a role extending xdg_surface, such as xdg_toplevel or xdg_popup.
>  
>   See the documentation of xdg_surface for more details about what an
>   xdg_surface is and how it is used.
> @@ -117,13 +115,18 @@
>
>  
>
> -
> +
>An interface that may be implemented by a wl_surface, for
>implementations that provide a desktop-style user interface.
>  
> -  It provides requests to treat surfaces like windows, allowing to set
> -  properties like maximized, fullscreen, minimized, and to move and 
> resize
> -  them, and associate metadata like title and app id.
> +  It provides a base set of functionality required to construct user
> +  interface elements requiring management by the compositor, such as
> +  toplevel windows, menus, etc. The types of functionality is split into 
> xdg
> +  surface roles.
> +
> +  Initially, an xdg_surface cannot be mapped, as the underlying 
> wl_surface
> +  has not been given any role. To give it a role, use one of the 
> functions
> +  creating xdg surface role specific objects: get_toplevel, get_popup.

I think this could be rephrased as something like

"Creating an xdg_surface does not set the role for a wl_surface. In order to map
an xdg_surface, create a role-specific object using, e.g., get_toplevel, 
get_popup.
The wl_surface for any given xdg_surface can have at most one role."

>  
>The client must call wl_surface.commit on the corresponding wl_surface
>for the xdg_surface state to take effect.
> @@ -139,6 +142,134 @@
>  
>  
>
> + Destroy the xdg_surface object. Before destroying the xdg_surface, any
> + xdg surface role object must have been previously destroyed.

Perhaps "An xdg_surface can only be destroyed after its role object has been 
destroyed" ?

> +  
> +
> +
> +
> +  
> + This creates an xdg_toplevel object for the given xdg_surface and gives
> + the associated wl_surface the xdg_toplevel role. A wl_surface can only
> + have one xdg_toplevel role. If the wl_surface is given the xdg_toplevel
> + role while it already has an active xdg_toplevel role, or if it has been
> + given any other role before, an error is raised.

Stating the restriction on number of roles for an xdg_surface in the 
xdg_surface part
would make this implicit for all of the roles. I think this would make future 
additions
simpler.

> +
> + See the documentation of xdg_toplevel for more details about what an
> + xdg_toplevel is and how it is used.
> +  
> +  
> +
> +
> +
> +  
> + This creates an xdg_popup object for the given xdg_surface and gives the
> + associated wl_surface the xdg_popup role. A wl_surface can only have one
> + xdg_popup role. If the wl_surface is given the xdg_popup role while it
> + already has an active xdg_popup role, or if it has been given any other
> + role before, an error is raised.
> +
> + This request must be used in response to some sort of user action like a
> + button press, key press, or touch down event.

Re: [PATCH] xdg-shell: add state range reservation for EFL

[Mike Blumenkrantz]

Yeah, that's my mistake, it got lost in the mail. If you don't mind adding

Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>

I would appreciate it.

On Sun, 06 Dec 2015 13:51:20 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> On Fri, Dec 04, 2015 at 12:41:16PM -0500, Mike Blumenkrantz wrote:
> > Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net>
> 
> Should this have a Signed-off-by? I remember something about that and
> Samsung.
> 
> 
> Jonas
> 
> > ---
> >  unstable/xdg-shell/xdg-shell-unstable-v5.xml | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > index 127992b..542491f 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > @@ -338,6 +338,7 @@
> >  
> >  0x - 0x0FFF: xdg-shell core values, documented below.
> >  0x1000 - 0x1FFF: GNOME
> > +0x2000 - 0x2FFF: EFL
> >
> >
> > 
> > -- 
> > 2.4.3
> > 
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH] xdg-shell: add state range reservation for EFL

[Mike Blumenkrantz]

Reviewed-by: Jasper St. Pierre 
---
 unstable/xdg-shell/xdg-shell-unstable-v5.xml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v5.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
index 127992b..542491f 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v5.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v5.xml
@@ -338,6 +338,7 @@
 
 0x - 0x0FFF: xdg-shell core values, documented below.
 0x1000 - 0x1FFF: GNOME
+0x2000 - 0x2FFF: EFL
   
   

-- 
2.4.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland-protocols v2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

On Fri, 04 Dec 2015 10:01:21 +0800
Jonas Ådahl <jad...@gmail.com> wrote:

> On Thu, Dec 03, 2015 at 05:38:34PM -0800, Bryce Harrington wrote:
> > On Fri, Dec 04, 2015 at 08:09:17AM +0800, Jonas Ådahl wrote:
> > > On Thu, Dec 03, 2015 at 03:26:16PM -0800, Bryce Harrington wrote:
> > > > On Thu, Dec 03, 2015 at 04:33:47PM +0800, Jonas Ådahl wrote:
> > > > > This copies the version 5 of the XML to a new version 6 version, while
> > > > > at the same time the interface names are changed to use the unstable
> > > > > naming convention.
> > > > > 
> > > > > A whitespace cleanup was done as no git-blame:ability would be lost
> > > > > anyway.
> > > > 
> > > > Just a bikeshed but would love to see tabs just go away in the xml
> > > > files.  They make protocol patches end up weirdly indented oftentimes.
> > > > Otherwise...
> > > 
> > > I too prefer spaces instead of tabs in XML files, but it seems spaces
> > > lost to tabs in what has become the overwhelming majority of indentation
> > > style in these XML files.
> > 
> > Was there an explicit reason to favor tabs?  Mere tradition seems not
> > terribly compelling given that we've forced a rename and migration to a
> > new repo only just recently.  I'd be happy to volunteer for their
> > replacement.
> 
> It was a realization that most of wayland.xml did this. I don't think
> there is enough gain by changing wayland.xml since we'd make git blame
> more hard to use, and consistency across protocols is favorable here
> IMHO.
> 

git blame -w ?

> 
> Jonas
> 
> > 
> > > > Reviewed-by: Bryce Harrington <br...@osg.samsung.com>
> > > 
> > > Thanks,
> > > 
> > > 
> > > Jonas
> > > 
> > > > 
> > > > > Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> > > > > Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> > > > >
> > > > > ---
> > > > > 
> > > > > Hey,
> > > > > 
> > > > > Made a mistake in the first version, so here comes a second version:
> > > > > 
> > > > > Changes since v1:
> > > > > 
> > > > > Updated the requests that take or create xdg_surface/xdg_popup objects
> > > > > use to the new names.
> > > > > 
> > > > > 
> > > > > Jonas
> > > > > 
> > > > > 
> > > > >  Makefile.am  |   1 +
> > > > >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 
> > > > > +++
> > > > >  2 files changed, 625 insertions(+)
> > > > >  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > 
> > > > > diff --git a/Makefile.am b/Makefile.am
> > > > > index 5926a41..4a2974d 100644
> > > > > --- a/Makefile.am
> > > > > +++ b/Makefile.am
> > > > > @@ -5,6 +5,7 @@ unstable_protocols =  
> > > > > \
> > > > >   unstable/text-input/text-input-unstable-v1.xml  
> > > > > \
> > > > >   unstable/input-method/input-method-unstable-v1.xml  
> > > > > \
> > > > >   unstable/xdg-shell/xdg-shell-unstable-v5.xml
> > > > > \
> > > > > + unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > \
> > > > >   $(NULL)
> > > > >  
> > > > >  nobase_dist_pkgdata_DATA =   
> > > > > \
> > > > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > new file mode 100644
> > > > > index 000..02a40ef
> > > > > --- /dev/null
> > > > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > > > @@ -0,0 +1,624 @@
> > > > > +
> > > > > +
> > > > > +
> > > > > +  
> > > > > +Copyright © 2008-2013 Kristian Høgsberg
> > > > > +Copyright © 2013  Rafael Antognolli
> > > > > +Copyright © 2013  Jasper St. Pierre
> > > > &

Re: [PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

On Wed, 02 Dec 2015 20:03:27 -0500
Mike Blumenkrantz <zm...@samsung.com> wrote:

> This copies the version 5 of the XML to a new version 6 version, while
> at the same time the interface names are changed to use the unstable
> naming convention.
> 
> A whitespace cleanup was done as no git-blame:ability would be lost
> anyway.
> 
> Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
> Signed-off-by: Jonas Ådahl <jad...@gmail.com>
> ---
>  Makefile.am  |   1 +
>  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624
> +++ 2 files changed, 625 insertions(+)
>  create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml
> 
> diff --git a/Makefile.am b/Makefile.am
> index 5926a41..4a2974d 100644
> --- a/Makefile.am
> +++ b/Makefile.am
> @@ -5,6 +5,7 @@ unstable_protocols
> = \
> unstable/text-input/text-input-unstable-v1.xml
> \
> unstable/input-method/input-method-unstable-v1.xml
> \
> unstable/xdg-shell/xdg-shell-unstable-v5.xml
> \
> +
> unstable/xdg-shell/xdg-shell-unstable-v6.xml
> \ $(NULL) 
>  nobase_dist_pkgdata_DATA
> = \ diff --git
> a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> b/unstable/xdg-shell/xdg-shell-unstable-v6.xml new file mode 100644
> index 000..196c332 --- /dev/null
> +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> @@ -0,0 +1,624 @@
> +
> +
> +
> +  
> +Copyright © 2008-2013 Kristian Høgsberg
> +Copyright © 2013  Rafael Antognolli
> +Copyright © 2013  Jasper St. Pierre
> +Copyright © 2010-2013 Intel Corporation
> +
> +Permission is hereby granted, free of charge, to any person
> obtaining a
> +copy of this software and associated documentation files (the
> "Software"),
> +to deal in the Software without restriction, including without
> limitation
> +the rights to use, copy, modify, merge, publish, distribute,
> sublicense,
> +and/or sell copies of the Software, and to permit persons to whom
> the
> +Software is furnished to do so, subject to the following
> conditions: +
> +The above copyright notice and this permission notice (including
> the next
> +paragraph) shall be included in all copies or substantial portions
> of the
> +Software.
> +
> +THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> EXPRESS OR
> +IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> MERCHANTABILITY,
> +FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
> SHALL
> +THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
> OR OTHER
> +LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
> ARISING
> +FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
> +DEALINGS IN THE SOFTWARE.
> +  
> +
> +  
> +
> +  xdg_shell allows clients to turn a wl_surface into a "real
> window"
> +  which can be dragged, resized, stacked, and moved around by the
> +  user. Everything about this interface is suited towards
> traditional
> +  desktop environments.
> +
> +
> +
> +  
> + The 'current' member of this enum gives the version of the
> + protocol.  Implementations can compare this to the version
> + they implement using static_assert to ensure the protocol and
> + implementation versions match.
> +  
> +  
> +
> +
> +
> +  
> +  
> +  
> +  
> +
> +
> +
> +  
> + Destroy this xdg_shell object.
> +
> + Destroying a bound xdg_shell object while there are surfaces
> + still alive created by this xdg_shell object instance is
> illegal
> + and will result in a protocol error.
> +  
> +
> +
> +
> +  
> + Negotiate the unstable version of the interface.  This
> + mechanism is in place to ensure client and server agree on the
> + unstable versions of the protocol that they speak or exit
> + cleanly if they don't agree.  This request will go away once
> + the xdg-shell protocol is stable.
> +  
> +  
> +
> +
> +
> +  
> + This creates an xdg_surface for the given surface and gives it
> the
> + xdg_surface role. A wl_surface can only be given an
> xdg_surface role
> + once. If get_xdg_surface is called with a wl_surface that
> already has
> + an active xdg_surface associated with it, or if it had any
> other role,
> + an error is raised.
> +
> + See

[PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

This copies the version 5 of the XML to a new version 6 version, while
at the same time the interface names are changed to use the unstable
naming convention.

A whitespace cleanup was done as no git-blame:ability would be lost
anyway.

Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 Makefile.am  |   1 +
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624 +++
 2 files changed, 625 insertions(+)
 create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml

diff --git a/Makefile.am b/Makefile.am
index 5926a41..4a2974d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols =
\
unstable/text-input/text-input-unstable-v1.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+   unstable/xdg-shell/xdg-shell-unstable-v6.xml
\
$(NULL)
 
 nobase_dist_pkgdata_DATA = 
\
diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
new file mode 100644
index 000..196c332
--- /dev/null
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -0,0 +1,624 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 Intel Corporation
+
+Permission is hereby granted, free of charge, to any person obtaining a
+copy of this software and associated documentation files (the "Software"),
+to deal in the Software without restriction, including without limitation
+the rights to use, copy, modify, merge, publish, distribute, sublicense,
+and/or sell copies of the Software, and to permit persons to whom the
+Software is furnished to do so, subject to the following conditions:
+
+The above copyright notice and this permission notice (including the next
+paragraph) shall be included in all copies or substantial portions of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards traditional
+  desktop environments.
+
+
+
+  
+   The 'current' member of this enum gives the version of the
+   protocol.  Implementations can compare this to the version
+   they implement using static_assert to ensure the protocol and
+   implementation versions match.
+  
+  
+
+
+
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Negotiate the unstable version of the interface.  This
+   mechanism is in place to ensure client and server agree on the
+   unstable versions of the protocol that they speak or exit
+   cleanly if they don't agree.  This request will go away once
+   the xdg-shell protocol is stable.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface and gives it the
+   xdg_surface role. A wl_surface can only be given an xdg_surface role
+   once. If get_xdg_surface is called with a wl_surface that already has
+   an active xdg_surface associated with it, or if it had any other role,
+   an error is raised.
+
+   See the documentation of xdg_surface for more details about what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   This creates an xdg_popup for the given surface and gives it the
+   xdg_popup role. A wl_surface can only be given an xdg_popup role
+   once. If get_xdg_popup is called with a wl_surface that already has
+   an active xdg_popup associated with it, or if it had any other role,
+   an error is raised.
+
+   This request must be used in response to some sort of user action
+   like a button press, key press, or touch d

[PATCH 2/2] xdg-shell: clarify xdg_surface creation semantics regarding buffers

[Mike Blumenkrantz]

this change ensures that the client will set its initial state
before performing any drawing, ensuring that there is no mismatch
when creating a surface with a non-default state
(eg. maximize, fullscreen, ...)

looking at the following event flows:
1) wl_surface.attach, wl_surface.commit, xdg_shell.get_xdg_surface

2) wl_surface.attach, xdg_shell.get_xdg_surface, wl_surface.commit

3) xdg_shell.get_xdg_surface, wl_surface.commit, xdg_surface.configure,
   wl_surface.attach, wl_surface.commit

only 3) is now valid, while 1) and 2) will trigger errors as a result
of handling buffers prior to creating the xdg surface

Reviewed-by: Jasper St. Pierre <jstpie...@mecheye.net>
Signed-off-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 14 ++
 1 file changed, 6 insertions(+), 8 deletions(-)

diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
index 196c332..a03a615 100644
--- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -147,14 +147,12 @@
   them, and associate metadata like title and app id.
 
   The client must call wl_surface.commit on the corresponding wl_surface
-  for the xdg_surface state to take effect. Prior to committing the new
-  state, it can set up initial configuration, such as maximizing or setting
-  a window geometry.
-
-  Even without attaching a buffer the compositor must respond to initial
-  committed configuration, for instance sending a configure event with
-  expected window geometry if the client maximized its surface during
-  initialization.
+  for the xdg_surface state to take effect.
+
+  Creating an xdg_surface from a wl_surface which has a buffer attached or
+  committed is a client error, and any attempts by a client to attach or
+  manipulate a buffer prior to the first xdg_surface.configure call must
+  also be treated as errors.
 
   For a surface to be mapped by the compositor the client must have
   committed both an xdg_surface state and a buffer.
-- 
2.4.3

___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

[PATCH 1/2] xdg-shell: Bump unstable version to 6

[Mike Blumenkrantz]

This copies the version 5 of the XML to a new version 6 version, while
at the same time the interface names are changed to use the unstable
naming convention.

A whitespace cleanup was done as no git-blame:ability would be lost
anyway.

Reviewed-by: Mike Blumenkrantz <zm...@osg.samsung.com>
Signed-off-by: Jonas Ådahl <jad...@gmail.com>
---
 Makefile.am  |   1 +
 unstable/xdg-shell/xdg-shell-unstable-v6.xml | 624
+++ 2 files changed, 625 insertions(+)
 create mode 100644 unstable/xdg-shell/xdg-shell-unstable-v6.xml

diff --git a/Makefile.am b/Makefile.am
index 5926a41..4a2974d 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -5,6 +5,7 @@ unstable_protocols
=   \
unstable/text-input/text-input-unstable-v1.xml
\
unstable/input-method/input-method-unstable-v1.xml
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
+
unstable/xdg-shell/xdg-shell-unstable-v6.xml
\ $(NULL) 
 nobase_dist_pkgdata_DATA
=   \ diff --git
a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
b/unstable/xdg-shell/xdg-shell-unstable-v6.xml new file mode 100644
index 000..196c332 --- /dev/null
+++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
@@ -0,0 +1,624 @@
+
+
+
+  
+Copyright © 2008-2013 Kristian Høgsberg
+Copyright © 2013  Rafael Antognolli
+Copyright © 2013  Jasper St. Pierre
+Copyright © 2010-2013 Intel Corporation
+
+Permission is hereby granted, free of charge, to any person
obtaining a
+copy of this software and associated documentation files (the
"Software"),
+to deal in the Software without restriction, including without
limitation
+the rights to use, copy, modify, merge, publish, distribute,
sublicense,
+and/or sell copies of the Software, and to permit persons to whom
the
+Software is furnished to do so, subject to the following
conditions: +
+The above copyright notice and this permission notice (including
the next
+paragraph) shall be included in all copies or substantial portions
of the
+Software.
+
+THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR
+IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
MERCHANTABILITY,
+FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT.  IN NO EVENT
SHALL
+THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES
OR OTHER
+LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE,
ARISING
+FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
+DEALINGS IN THE SOFTWARE.
+  
+
+  
+
+  xdg_shell allows clients to turn a wl_surface into a "real
window"
+  which can be dragged, resized, stacked, and moved around by the
+  user. Everything about this interface is suited towards
traditional
+  desktop environments.
+
+
+
+  
+   The 'current' member of this enum gives the version of the
+   protocol.  Implementations can compare this to the version
+   they implement using static_assert to ensure the protocol and
+   implementation versions match.
+  
+  
+
+
+
+  
+  
+  
+  
+
+
+
+  
+   Destroy this xdg_shell object.
+
+   Destroying a bound xdg_shell object while there are surfaces
+   still alive created by this xdg_shell object instance is
illegal
+   and will result in a protocol error.
+  
+
+
+
+  
+   Negotiate the unstable version of the interface.  This
+   mechanism is in place to ensure client and server agree on the
+   unstable versions of the protocol that they speak or exit
+   cleanly if they don't agree.  This request will go away once
+   the xdg-shell protocol is stable.
+  
+  
+
+
+
+  
+   This creates an xdg_surface for the given surface and gives it
the
+   xdg_surface role. A wl_surface can only be given an
xdg_surface role
+   once. If get_xdg_surface is called with a wl_surface that
already has
+   an active xdg_surface associated with it, or if it had any
other role,
+   an error is raised.
+
+   See the documentation of xdg_surface for more details about
what an
+   xdg_surface is and how it is used.
+  
+  
+  
+
+
+
+  
+   This creates an xdg_popup for the given surface and gives it
the
+   xdg_popup role. A wl_surface can only be given an xdg_popup
role
+   once. If get_xdg_popup is called with a wl_surface that
already has
+   an active xdg_popup associated with it, or if it had any other
role,
+   an error is raised.
+
+   This request must be used in response to some sort of user
action
+   like a button press, key press, or touch down event.
+
+   See the documentation of xdg_popup for more details about what

Re: [PATCH wayland] protocol: Improve data source notification around DnD progress

[Mike Blumenkrantz]

On Fri, 16 Oct 2015 16:53:28 +0100
Daniel Stone  wrote:

> Hi,
> 
> On Wednesday, 30 September 2015, Carlos Garnacho 
> wrote:
> 
> > Currently, there's no means for the DnD origin to know whether the
> > destination is actually finished with the DnD transaction, short of
> > finalizing it after the first transfer finishes, or leaking it
> > forever.
> >
> > But this poses other interoperation problems, drag destinations
> > might be requesting several mimetypes at once, might be just poking
> > to find out the most suitable format, might want to defer the
> > action to a popup, might be poking contents early before the
> > selection was dropped...
> >
> > In addition, data_source.cancelled is suitable for the situations
> > where the DnD operation fails (not on a drop target, no matching
> > mimetypes, etc..), but seems undocumented for that use (and unused
> > in weston's DnD).
> >
> > In order to improve the situation, the drag source should be
> > notified of all stages of DnD. In addition to documenting the
> > "cancelled" event for DnD purposes, The following 2 events have
> > been added:
> >
> > - wl_data_source.drop_performed: Happens when the operation has been
> >   physically finished (eg. the button is released), it could be the
> > right place to reset the pointer cursor back and undo any other
> > state resulting from the initial button press.
> > - wl_data_source.drag_finished: Happens when the destination side
> > destroys the wl_data_offer, at this point the source can just
> > forget all data related to the DnD selection as well, plus
> > optionally deleting the data on move operations.
> >
> > Signed-off-by: Carlos Garnacho >
> 
> 
>  Mike had a look at this from EFL - CCing him.
> 
> Cheers,
> Daniel

Hi,

Having reviewed this, and also having fully implemented the current DND
protocol, I think that this is a good idea and would be a worthwhile
addition. I have no suggestions for modifications or trivial
bikeshedding.

Regards,
Mike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: [PATCH wayland v4] protocol: Add DnD actions

[Mike Blumenkrantz]

On Fri, 16 Oct 2015 16:52:44 +0100
Daniel Stone  wrote:

> Hi,
> 
> On Wednesday, 30 September 2015, Carlos Garnacho 
> wrote:
> 
> > These 2 requests have been added:
> >
> > - wl_data_source.set_actions: Notifies the compositor of the
> > available actions on the data source.
> > - wl_data_offer.set_actions: Notifies the compositor of the
> > available actions on the destination side, plus the preferred
> > action.
> >
> > Out of the data from these requests, the compositor can determine
> > the action
> > both parts agree on (and let the user play a role through eg.
> > keyboard modifiers). The chosen option will be notified to both
> > parties through the following two requests:
> >
> > - wl_data_source.action
> > - wl_data_offer.action
> >
> > In addition, the destination side can peek the source side actions
> > through wl_data_offer.source_actions.
> >
> > Compared to the XDND protocol, there's two notable changes:
> >
> > - XDND lets the source suggest an action, whereas wl_data_device
> > lets the destination prefer a given action. The difference is
> > subtle here, it comes off as convenience because it is the drag
> > destination which receives the motion events (unlike in X) and can
> > perform action updates.
> >
> >   The drag destination seems also in a better position to update the
> >   preferred action based on things like the data being transferred,
> > the place being dropped, and whether the drag is client-local.
> >
> > - That same source-side preferred action is used in XDND to convey
> > the modifier-induced action to the drag destination, which would
> > then ack it, or reply with another action that's accepted (or
> > none), this makes the XdndPosition/XdndStatus messaging very
> > verbose, and synchronous because the drag source always needs to
> > know the latest status/action for every position+action sent.
> >
> >   Here it's the compositor which takes care of modifiers and
> > matching available/accepted actions, this allows for the signaling
> > to happen only whenever the actions/modifiers change for real.
> >
> > Roughly based on previous work by Giulio Camuffo
> > >
> >
> 
> Mike had a look at this from EFL - CCing him.
> 
> Cheers,
> Daniel

Hi,

Having reviewed this, and also having fully implemented the current DND
protocol, I think that this is a good idea and would be a worthwhile
addition. I have no suggestions for modifications or trivial
bikeshedding.

Regards,
Mike
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel