[PATCH wayland-protocols v3 2/7] xdg-shell: Put xdg_shell events after requests

[Jonas Ådahl]

On Wed, Jun 08, 2016 at 04:48:10PM +0200, Benoit Gschwind wrote:
> Hello Jonas,
> 
> look good, few comment ahead.
> 
> On 26/05/2016 06:32, Jonas Ådahl wrote:
> > It makes the structure consistent with most other protocols and
> > provides a clear separation between what is done by the server and what
> > is done by the client.
> > 
> > Signed-off-by: Jonas Ådahl <jadahl at gmail.com>
> > Reviewed-by: Yong Bakos <ybakos at humanoriented.com>
> > Reviewed-by: Mike Blumenkrantz <zmike at osg.samsung.com>
> > ---
> >  unstable/xdg-shell/xdg-shell-unstable-v6.xml | 74 ++++++++++++++--------------
> >  1 file changed, 37 insertions(+), 37 deletions(-)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index fa838f9..c7036f5 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -65,6 +65,14 @@
> >        <arg name="surface" type="object" interface="wl_surface"/>
> >      </request>
> >  
> > +    <request name="pong">
> > +      <description summary="respond to a ping event">
> > +	A client must respond to a ping event with a pong request or
> > +	the client may be deemed unresponsive.
> > +      </description>
> > +      <arg name="serial" type="uint" summary="serial of the ping event"/>
> > +    </request>
> > +
> 
> as you swaped the ping-pong order I suggest to add :
> 
> See "ping" event description for more details.

Sure, makes sense to reference the other event/request.


Jonas

> 
> >      <event name="ping">
> >        <description summary="check if the client is alive">
> >  	The ping event asks the client if it's still alive. Pass the
> > @@ -81,14 +89,6 @@
> >        </description>
> >        <arg name="serial" type="uint" summary="pass this to the pong request"/>
> >      </event>
> > -
> > -    <request name="pong">
> > -      <description summary="respond to a ping event">
> > -	A client must respond to a ping event with a pong request or
> > -	the client may be deemed unresponsive.
> > -      </description>
> > -      <arg name="serial" type="uint" summary="serial of the ping event"/>
> > -    </request>
> >    </interface>
> >  
> >    <interface name="zxdg_surface_v6" version="1">
> > @@ -465,35 +465,6 @@
> >        </entry>
> >      </enum>
> >  
> > -    <event name="configure">
> > -      <description summary="suggest a surface change">
> > -	This configure event asks the client to resize its toplevel surface or
> > -	to change its state. It is not sent by itself but as a latched state
> > -	sent prior to the xdg_surface.configure event. See xdg_surface.configure
> > -	for details.
> > -
> > -	The width and height arguments specify a hint to the window
> > -	about how its surface should be resized in window geometry
> > -	coordinates. See set_window_geometry.
> > -
> > -	If the width or height arguments are zero, it means the client
> > -	should decide its own window dimension. This may happen when the
> > -	compositor need to configure the state of the surface but doesn't
> > -	have any information about any previous or expected dimension.
> > -
> > -	The states listed in the event specify how the width/height
> > -	arguments should be interpreted, and possibly how it should be
> > -	drawn.
> > -
> > -	Clients must send an ack_configure in response to this event. See
> > -	xdg_surface.configure and xdg_surface.ack_configure for details.
> > -      </description>
> > -
> > -      <arg name="width" type="int"/>
> > -      <arg name="height" type="int"/>
> > -      <arg name="states" type="array"/>
> > -    </event>
> > -
> >      <request name="set_max_size">
> >        <description summary="set the maximum size">
> >  	Set a maximum size for the window.
> > @@ -648,6 +619,35 @@
> >        </description>
> >      </request>
> >  
> > +    <event name="configure">
> > +      <description summary="suggest a surface change">
> > +	This configure event asks the client to resize its toplevel surface or
> > +	to change its state. It is not sent by itself but as a latched state
> > +	sent prior to the xdg_surface.configure event. See xdg_surface.configure
> > +	for details.
> > +
> > +	The width and height arguments specify a hint to the window
> > +	about how its surface should be resized in window geometry
> > +	coordinates. See set_window_geometry.
> > +
> > +	If the width or height arguments are zero, it means the client
> > +	should decide its own window dimension. This may happen when the
> > +	compositor need to configure the state of the surface but doesn't
> > +	have any information about any previous or expected dimension.
> > +
> > +	The states listed in the event specify how the width/height
> > +	arguments should be interpreted, and possibly how it should be
> > +	drawn.
> > +
> > +	Clients must send an ack_configure in response to this event. See
> > +	xdg_surface.configure and xdg_surface.ack_configure for details.
> > +      </description>
> > +
> > +      <arg name="width" type="int"/>
> > +      <arg name="height" type="int"/>
> > +      <arg name="states" type="array"/>
> > +    </event>
> > +
> >      <event name="close">
> >        <description summary="surface wants to be closed">
> >  	The close event is sent by the compositor when the user
> > 
> 
> Best regards
> 
> --
> Benoit Gschwind