Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Nils Chr. Brause]

Hi!

On Fri, Jul 29, 2016 at 10:52 AM, Pekka Paalanen  wrote:
> On Fri, 22 Jul 2016 21:39:20 +0200
> "Nils Chr. Brause"  wrote:
>
>> HI,
>>
>> On Thu, Jun 2, 2016 at 10:30 AM, Pekka Paalanen  wrote:
>> > On Thu, 2 Jun 2016 15:39:47 +0800
>> > Jonas Ådahl  wrote:
>> >
>> >> On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:
>> >> > On Wed, 1 Jun 2016 13:16:31 -0500
>> >> > Yong Bakos  wrote:
>> >> >
>> >> > > On May 30, 2016, at 3:54 AM, Pekka Paalanen  
>> >> > > wrote:
>> >> > > >
>> >> > > > On Sat, 28 May 2016 08:39:59 -0500
>> >> > > > Yong Bakos  wrote:
>> >> > > >
>> >> > > >> Hi Mike,
>> >> > > >> Regarding the combination of type="array" enum="foo"...
>> >> > > >>
>> >> > > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>> >> > > >>>  wrote:
>> >> > > >>>
>> >> > > >>> I've inlined some replies below.
>> >> > > >>>
>> >> > > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos 
>> >> > > >>> > wrote:
>> >> > > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
>> >> > > >>> > wrote:
>> >> > > 
>> >> > >  this adds a method for compositors to change various draw 
>> >> > >  attributes
>> >> > >  for a surface
>> >> > > 
>> >> > >  Signed-off-by: Mike Blumenkrantz > >> > >  >
>> >> > >  Signed-off-by: Jonas Ådahl > >> > >  >
>> >> > > >>>
>> >> > > >>> 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
>> >> > > >
>> >> > >  +
>> >> > >  +Calling this after an xdg_toplevel's first commit will 
>> >> > >  raise a client error.
>> >> > >  +  
>> >> > >  +  
>> >> > > >>>
>> >> > > >>> Just a sanity check, since I haven't seen it in a protocol spec 
>> >> > > >>> yet. Does scanner handle
>> >> > > >>> this combination of array and enum correctly?
>> >> > > >>>
>> >> > > >>> Good catch. This also affects the event above it.
>> >> > > >>
>> >> > > >> As we discussed via IRC (27 May), the scanner will choke on this. 
>> >> > > >> While we talked about
>> >> > > >> making a change to the scanner to allow this, perhaps such a 
>> >> > > >> change doesn't make sense.
>> >> > > >>
>> >> > > >> Given a type="array", scanner will generate a parameter of type 
>> >> > > >> wl_array.
>> >> > > >>
>> >> > > >> Perhaps the short story here is to just remove the enum from this 
>> >> > > >> arg, and the similar
>> >> > > >> arg in the configure_draw_states event above. What do you think?
>> >> > > >>
>> >> > > >> (I wonder if it's the DTD that can change, so the scanner's 
>> >> > > >> validation step
>> >> > > >> will catch the unsupported combination of type="array" enum="foo". 
>> >> > > >> My gut tells me that
>> >> > > >> DTDs don't support this logic, but I'll dig into this.)
>> >> > > >
>> >> > > > Hi,
>> >> > > >
>> >> > > > here is some background.
>> >> > > >
>> >> > > > A type="array" argument is really just a binary blob of data. The 
>> >> > > > XML
>> >> > > > description, human documentation aside, does not specify anything 
>> >> > > > about
>> >> > > > the blob contents. Therefore adding an XML attribute pointing to an
>> >> > > > enum definition is half-useless. Generators could use it for 
>> >> > > > creating
>> >> > > > automatic links in documentation, but it cannot be used for code
>> >> > > > generation, because you don't know the types contained in the blob.
>> >> > > >
>> >> > > > We also do not want to add blob content type definitions to the XML
>> >> > > > language, because you might want to have everything C is able to
>> >> > > > express, including nested structs. There is also no requirement that
>> >> > > > the "array" is really an array - every "element" could be a 
>> >> > > > different
>> >> > > > thing. It could be bitstream and whatnot. Only the use of
>> >> > > > wl_array_for_each() implies it is an array of similar elements,
>> >> > > > wl_array_add() does not.
>>
>> Then that's not an 'array' than but more like a struct.
>> Therefore the structure definition should be in the XML.
>> 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Pekka Paalanen]

On Fri, 22 Jul 2016 21:39:20 +0200
"Nils Chr. Brause"  wrote:

> HI,
> 
> On Thu, Jun 2, 2016 at 10:30 AM, Pekka Paalanen  wrote:
> > On Thu, 2 Jun 2016 15:39:47 +0800
> > Jonas Ådahl  wrote:
> >  
> >> On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:  
> >> > On Wed, 1 Jun 2016 13:16:31 -0500
> >> > Yong Bakos  wrote:
> >> >  
> >> > > On May 30, 2016, at 3:54 AM, Pekka Paalanen  
> >> > > wrote:  
> >> > > >
> >> > > > On Sat, 28 May 2016 08:39:59 -0500
> >> > > > Yong Bakos  wrote:
> >> > > >  
> >> > > >> Hi Mike,
> >> > > >> Regarding the combination of type="array" enum="foo"...
> >> > > >>  
> >> > > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> >> > > >>>  wrote:
> >> > > >>>
> >> > > >>> I've inlined some replies below.
> >> > > >>>
> >> > > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  >> > > >>> > wrote:
> >> > > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
> >> > > >>> > wrote:  
> >> > > 
> >> > >  this adds a method for compositors to change various draw 
> >> > >  attributes
> >> > >  for a surface
> >> > > 
> >> > >  Signed-off-by: Mike Blumenkrantz  >> > >  >
> >> > >  Signed-off-by: Jonas Ådahl  >> > >  >  
> >> > > >>>
> >> > > >>> 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  
> >> > > >  
> >> > >  +
> >> > >  +Calling this after an xdg_toplevel's first commit will 
> >> > >  raise a client error.
> >> > >  +  
> >> > >  +
> >> > > >>>
> >> > > >>> Just a sanity check, since I haven't seen it in a protocol spec 
> >> > > >>> yet. Does scanner handle
> >> > > >>> this combination of array and enum correctly?
> >> > > >>>
> >> > > >>> Good catch. This also affects the event above it.  
> >> > > >>
> >> > > >> As we discussed via IRC (27 May), the scanner will choke on this. 
> >> > > >> While we talked about
> >> > > >> making a change to the scanner to allow this, perhaps such a change 
> >> > > >> doesn't make sense.
> >> > > >>
> >> > > >> Given a type="array", scanner will generate a parameter of type 
> >> > > >> wl_array.
> >> > > >>
> >> > > >> Perhaps the short story here is to just remove the enum from this 
> >> > > >> arg, and the similar
> >> > > >> arg in the configure_draw_states event above. What do you think?
> >> > > >>
> >> > > >> (I wonder if it's the DTD that can change, so the scanner's 
> >> > > >> validation step
> >> > > >> will catch the unsupported combination of type="array" enum="foo". 
> >> > > >> My gut tells me that
> >> > > >> DTDs don't support this logic, but I'll dig into this.)  
> >> > > >
> >> > > > Hi,
> >> > > >
> >> > > > here is some background.
> >> > > >
> >> > > > A type="array" argument is really just a binary blob of data. The XML
> >> > > > description, human documentation aside, does not specify anything 
> >> > > > about
> >> > > > the blob contents. Therefore adding an XML attribute pointing to an
> >> > > > enum definition is half-useless. Generators could use it for creating
> >> > > > automatic links in documentation, but it cannot be used for code
> >> > > > generation, because you don't know the types contained in the blob.
> >> > > >
> >> > > > We also do not want to add blob content type definitions to the XML
> >> > > > language, because you might want to have everything C is able to
> >> > > > express, including nested structs. There is also no requirement that
> >> > > > the "array" is really an array - every "element" could be a different
> >> > > > thing. It could be bitstream and whatnot. Only the use of
> >> > > > wl_array_for_each() implies it is an array of similar elements,
> >> > > > wl_array_add() does not.  
> 
> Then that's not an 'array' than but more like a struct.
> Therefore the structure definition should be in the XML.
> Leaving it undocumented is a terrible option.

Hi Nils,

yes, things should definitely be documented. I mean human-readable
documentation, not necessarily machine-parseable description.

> >> > > > The 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Nils Chr. Brause]

HI,

On Thu, Jun 2, 2016 at 10:30 AM, Pekka Paalanen  wrote:
> On Thu, 2 Jun 2016 15:39:47 +0800
> Jonas Ådahl  wrote:
>
>> On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:
>> > On Wed, 1 Jun 2016 13:16:31 -0500
>> > Yong Bakos  wrote:
>> >
>> > > On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
>> > > >
>> > > > On Sat, 28 May 2016 08:39:59 -0500
>> > > > Yong Bakos  wrote:
>> > > >
>> > > >> Hi Mike,
>> > > >> Regarding the combination of type="array" enum="foo"...
>> > > >>
>> > > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>> > > >>>  wrote:
>> > > >>>
>> > > >>> I've inlined some replies below.
>> > > >>>
>> > > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos > > > >>> > wrote:
>> > > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
>> > > >>> > wrote:
>> > > 
>> > >  this adds a method for compositors to change various draw attributes
>> > >  for a surface
>> > > 
>> > >  Signed-off-by: Mike Blumenkrantz > > >  >
>> > >  Signed-off-by: Jonas Ådahl > > >  >
>> > > >>>
>> > > >>> 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
>> > > >
>> > >  +
>> > >  +Calling this after an xdg_toplevel's first commit will 
>> > >  raise a client error.
>> > >  +  
>> > >  +  
>> > > >>>
>> > > >>> Just a sanity check, since I haven't seen it in a protocol spec yet. 
>> > > >>> Does scanner handle
>> > > >>> this combination of array and enum correctly?
>> > > >>>
>> > > >>> Good catch. This also affects the event above it.
>> > > >>
>> > > >> As we discussed via IRC (27 May), the scanner will choke on this. 
>> > > >> While we talked about
>> > > >> making a change to the scanner to allow this, perhaps such a change 
>> > > >> doesn't make sense.
>> > > >>
>> > > >> Given a type="array", scanner will generate a parameter of type 
>> > > >> wl_array.
>> > > >>
>> > > >> Perhaps the short story here is to just remove the enum from this 
>> > > >> arg, and the similar
>> > > >> arg in the configure_draw_states event above. What do you think?
>> > > >>
>> > > >> (I wonder if it's the DTD that can change, so the scanner's 
>> > > >> validation step
>> > > >> will catch the unsupported combination of type="array" enum="foo". My 
>> > > >> gut tells me that
>> > > >> DTDs don't support this logic, but I'll dig into this.)
>> > > >
>> > > > Hi,
>> > > >
>> > > > here is some background.
>> > > >
>> > > > A type="array" argument is really just a binary blob of data. The XML
>> > > > description, human documentation aside, does not specify anything about
>> > > > the blob contents. Therefore adding an XML attribute pointing to an
>> > > > enum definition is half-useless. Generators could use it for creating
>> > > > automatic links in documentation, but it cannot be used for code
>> > > > generation, because you don't know the types contained in the blob.
>> > > >
>> > > > We also do not want to add blob content type definitions to the XML
>> > > > language, because you might want to have everything C is able to
>> > > > express, including nested structs. There is also no requirement that
>> > > > the "array" is really an array - every "element" could be a different
>> > > > thing. It could be bitstream and whatnot. Only the use of
>> > > > wl_array_for_each() implies it is an array of similar elements,
>> > > > wl_array_add() does not.

Then that's not an 'array' than but more like a struct.
Therefore the structure definition should be in the XML.
Leaving it undocumented is a terrible option.

>> > > > The big point in adding enum annotations was that language bindings
>> > > > generators (other than wayland-scanner) could use the annotation for
>> > > > code generation. I don't think it is possible with the array type.

Of course it is. If we properly define its contents, language bindings
could put the
proper structure into the argument list of the particular requests/events.

>> > > >
>> > > > If we allow enum annotation with the array type, it will only be usable
>> > > > for doc links, unlike the 

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

[Benoit Gschwind]

Hello Olivier,

On 07/06/2016 11:15, Olivier Fourdan wrote:
> Hi Benoit,
> 
> - Original Message -
>> On 07/06/2016 10:30, Olivier Fourdan wrote:
>>> [...]
>>> I disagree here, if anything we should keep the semantic states separate,
>>> we wouldn't want to have something like "no_shadow" or "no_border" as a
>>> semantic state like "maximized" or "fullscreen", do we?
>>
>> fullscreen and maximized are shortcut for drawing states:
>>
>>  * fullscreen = no_border+no_shadow
>>  * maximized = no_shadow+no_maximized_button+reduce_button
>>
>> what about activated state, that basically mean draw it as activated ?
> 
> No, a window being "active" remains true independently of the compositor 
> running, whereas the "draw states" are a way to negotiate between the 
> compositor and the application which one would be drawing some of the 
> decorations/controls.

are we reading the same specification? citation: (xdg-shell-unstable-v6.xml)



  Client window decorations should be painted as if the window is
  active. Do not assume this means that the window actually has
  keyboard or pointer focus.



The active state is a state that the compositor choose, and they do not
remain if there is no compositor.

> 
> A compositor may wish apps to be without drop shadow no matter the state, 
> active, fullscreen, maximized, tiled or other. 
> 

The state activated can be applied to fullscreen, maximized or tiled,
exactly as without_shadow.

>> This is too difficult to draw a line between draw states and "behaviors"
>> states, they are linked.
> 
> The semantic states imply a well commonly accepted presentation (like 
> fullscreen, all window controls are hidden), but the opposite isn't true, 
> it's impossible to deduce a state from just the presentations flags.

Which level of complexity have to be a semantic state to be a /semantic
state/: see activated state above.

>> I think we should think about window state once more :D
> 
> I reckon the current states as defined in xdg-shell are commonly understood, 
> established and accepted between environments, I don't see the need to change 
> that.
> 

Same here, I do not want change current states, just add some.
I prefer this than using a work-around to avoid decision policy.

> Cheers,
> Olivier
> 

Best regards
--
Benoit Gschwind

___
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

[Benoit Gschwind]

Hello Jonas,

I understand your point, and also we bike-shedding. if you add
not_shadowed state to the state list you solve the first part of the
issue. I do not think we need more states list.

Next issue is to how advertise to the compositor which optional states
are supported by the client. In that case your proposal is fine:
set_available_states. Maybe it could be client wide, but the per surface
is fine.

I don't think adding a separate state list help to make it accepted. For
me adding those list, look like saying: "your are reluctant to add state
to the state list, thus I create a new list, it's better isn't it ?"

This is my opinion.

Best regards.

On 07/06/2016 10:59, Jonas Ådahl wrote:
> On Tue, Jun 07, 2016 at 10:47:13AM +0200, Benoit Gschwind wrote:
>> Hello Olivier
>>
>> On 07/06/2016 10:30, Olivier Fourdan wrote:
>>> Hi Benoit,
>>>
>>> - Original Message -
 [...]

 My primary complain is that draw states should be merged with the
 previously defined window/surface states, because by definition a draw
 state is a state for a window, just like the state activated for example.
>>>
>>> I disagree here, if anything we should keep the semantic states separate, 
>>> we wouldn't want to have something like "no_shadow" or "no_border" as a 
>>> semantic state like "maximized" or "fullscreen", do we?
>>>
>>
>> fullscreen and maximized are shortcut for drawing states:
>>
>>  * fullscreen = no_border+no_shadow
>>  * maximized = no_shadow+no_maximized_button+reduce_button
>>
>> what about activated state, that basically mean draw it as activated ?
>>
>> This is too difficult to draw a line between draw states and "behaviors"
>> states, they are linked.
>>
>> I think we should think about window state once more :D
> 
> The point is to separate semantical states, where the interpretation of
> how the state translates into how a client draws its content is mostly
> up to the client itself, from draw states, which more strictly defines
> what exactly is different and whether the responsibility of drawing
> those parts may or may not be moved from the client elsewhere.
> 
> For example, fullscreen is not "no border + no shadow", it may involve
> various other things, and we are not going to define all those things in
> a gigantic state enum when the end result for the compositor is all the
> same.
> 
> 
> Jonas
> 
>>
>>> Cheers,
>>> Olivier
>>> ___
>>> wayland-devel mailing list
>>> wayland-devel@lists.freedesktop.org
>>> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
>>>
>>
>> Best regards
>> --
>> Benoit Gschwind
>> ___
>> 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] xdg-shell: add draw states for xdg_surface

[Olivier Fourdan]

Hi Benoit,

- Original Message -
> On 07/06/2016 10:30, Olivier Fourdan wrote:
> > [...]
> > I disagree here, if anything we should keep the semantic states separate,
> > we wouldn't want to have something like "no_shadow" or "no_border" as a
> > semantic state like "maximized" or "fullscreen", do we?
> 
> fullscreen and maximized are shortcut for drawing states:
> 
>  * fullscreen = no_border+no_shadow
>  * maximized = no_shadow+no_maximized_button+reduce_button
> 
> what about activated state, that basically mean draw it as activated ?

No, a window being "active" remains true independently of the compositor 
running, whereas the "draw states" are a way to negotiate between the 
compositor and the application which one would be drawing some of the 
decorations/controls.

A compositor may wish apps to be without drop shadow no matter the state, 
active, fullscreen, maximized, tiled or other. 

> This is too difficult to draw a line between draw states and "behaviors"
> states, they are linked.

The semantic states imply a well commonly accepted presentation (like 
fullscreen, all window controls are hidden), but the opposite isn't true, it's 
impossible to deduce a state from just the presentations flags.

> I think we should think about window state once more :D

I reckon the current states as defined in xdg-shell are commonly understood, 
established and accepted between environments, I don't see the need to change 
that.

Cheers,
Olivier
___
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

[Jonas Ådahl]

On Tue, Jun 07, 2016 at 10:47:13AM +0200, Benoit Gschwind wrote:
> Hello Olivier
> 
> On 07/06/2016 10:30, Olivier Fourdan wrote:
> > Hi Benoit,
> > 
> > - Original Message -
> >> [...]
> >>
> >> My primary complain is that draw states should be merged with the
> >> previously defined window/surface states, because by definition a draw
> >> state is a state for a window, just like the state activated for example.
> > 
> > I disagree here, if anything we should keep the semantic states separate, 
> > we wouldn't want to have something like "no_shadow" or "no_border" as a 
> > semantic state like "maximized" or "fullscreen", do we?
> > 
> 
> fullscreen and maximized are shortcut for drawing states:
> 
>  * fullscreen = no_border+no_shadow
>  * maximized = no_shadow+no_maximized_button+reduce_button
> 
> what about activated state, that basically mean draw it as activated ?
> 
> This is too difficult to draw a line between draw states and "behaviors"
> states, they are linked.
> 
> I think we should think about window state once more :D

The point is to separate semantical states, where the interpretation of
how the state translates into how a client draws its content is mostly
up to the client itself, from draw states, which more strictly defines
what exactly is different and whether the responsibility of drawing
those parts may or may not be moved from the client elsewhere.

For example, fullscreen is not "no border + no shadow", it may involve
various other things, and we are not going to define all those things in
a gigantic state enum when the end result for the compositor is all the
same.


Jonas

> 
> > Cheers,
> > Olivier
> > ___
> > wayland-devel mailing list
> > wayland-devel@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> > 
> 
> Best regards
> --
> Benoit Gschwind
> ___
> 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: add draw states for xdg_surface

[Benoit Gschwind]

Hello Olivier

On 07/06/2016 10:30, Olivier Fourdan wrote:
> Hi Benoit,
> 
> - Original Message -
>> [...]
>>
>> My primary complain is that draw states should be merged with the
>> previously defined window/surface states, because by definition a draw
>> state is a state for a window, just like the state activated for example.
> 
> I disagree here, if anything we should keep the semantic states separate, we 
> wouldn't want to have something like "no_shadow" or "no_border" as a semantic 
> state like "maximized" or "fullscreen", do we?
> 

fullscreen and maximized are shortcut for drawing states:

 * fullscreen = no_border+no_shadow
 * maximized = no_shadow+no_maximized_button+reduce_button

what about activated state, that basically mean draw it as activated ?

This is too difficult to draw a line between draw states and "behaviors"
states, they are linked.

I think we should think about window state once more :D

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

Best regards
--
Benoit Gschwind
___
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

[Olivier Fourdan]

Hi Benoit,

- Original Message -
> [...]
> 
> My primary complain is that draw states should be merged with the
> previously defined window/surface states, because by definition a draw
> state is a state for a window, just like the state activated for example.

I disagree here, if anything we should keep the semantic states separate, we 
wouldn't want to have something like "no_shadow" or "no_border" as a semantic 
state like "maximized" or "fullscreen", do we?

Cheers,
Olivier
___
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

[Benoit Gschwind]

Hello Matthias,

I agree the two reply from Jonas, and Olivier.

I just add to Olivier comment, that even we tried to remove MWM hints
(i.e. they do not belong any up-to-date standards), they are still used
by up-to-date software and implemented by popular WMs. This use case
show that (1) those hints are useful and (2) they do not have noticeable
draw back.

My primary complain is that draw states should be merged with the
previously defined window/surface states, because by definition a draw
state is a state for a window, just like the state activated for example.

Best regards.

On 07/06/2016 10:00, Olivier Fourdan wrote:
> Hi Jonas,
> 
> - Original Message -
>> On Mon, Jun 06, 2016 at 09:50:19AM -0400, Matthias Clasen wrote:
>>> To me, 'draw states' sounds a lot like 'mwm hints' - which would be a
>>> 180 degree reversal from semantic states back to presentation states.
>>> Do we really want to go down that road ?
>>
>> I'm not too familiar with MWM hints, but this does not affect the
>> semantic states, nor will it replace any of them. They'll all be
>> optional, and they are mostly meant to be used by DE:s that wants to
>> opt-in on non-default behaviours.
> 
> Yeah, but still not unlike EMWH vs. MWM hints, in X11 you can have a EWMH 
> semantics and apply additional presentation tweaks using MWM, that's how gtk+ 
> achieves CSD in X11 for example, it uses MWM hints to tell the WM not to 
> decorate the window.
> 
> Cheers,
> Olivier
> ___
> wayland-devel mailing list
> wayland-devel@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/wayland-devel
> 
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

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

[Olivier Fourdan]

Hi Jonas,

- Original Message -
> On Mon, Jun 06, 2016 at 09:50:19AM -0400, Matthias Clasen wrote:
> > To me, 'draw states' sounds a lot like 'mwm hints' - which would be a
> > 180 degree reversal from semantic states back to presentation states.
> > Do we really want to go down that road ?
> 
> I'm not too familiar with MWM hints, but this does not affect the
> semantic states, nor will it replace any of them. They'll all be
> optional, and they are mostly meant to be used by DE:s that wants to
> opt-in on non-default behaviours.

Yeah, but still not unlike EMWH vs. MWM hints, in X11 you can have a EWMH 
semantics and apply additional presentation tweaks using MWM, that's how gtk+ 
achieves CSD in X11 for example, it uses MWM hints to tell the WM not to 
decorate the window.

Cheers,
Olivier
___
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

[Jonas Ådahl]

On Mon, Jun 06, 2016 at 09:50:19AM -0400, Matthias Clasen wrote:
> To me, 'draw states' sounds a lot like 'mwm hints' - which would be a
> 180 degree reversal from semantic states back to presentation states.
> Do we really want to go down that road ?

I'm not too familiar with MWM hints, but this does not affect the
semantic states, nor will it replace any of them. They'll all be
optional, and they are mostly meant to be used by DE:s that wants to
opt-in on non-default behaviours.


Jonas

> ___
> 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: add draw states for xdg_surface

[Matthias Clasen]

To me, 'draw states' sounds a lot like 'mwm hints' - which would be a
180 degree reversal from semantic states back to presentation states.
Do we really want to go down that road ?
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Yong Bakos]

On Jun 2, 2016, at 4:26 AM, Auke Booij  wrote:
> 
> On 1 June 2016 at 20:16, Yong Bakos  wrote:
>> On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
>>> 
>>> On Sat, 28 May 2016 08:39:59 -0500
>>> Yong Bakos  wrote:
>>> 
 Hi Mike,
 Regarding the combination of type="array" enum="foo"...
 
> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>  wrote:
> 
> I've inlined some replies below.
> 
> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > wrote:
> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  > wrote:
>> 
>> this adds a method for compositors to change various draw attributes
>> for a surface
>> 
>> Signed-off-by: Mike Blumenkrantz > >
>> Signed-off-by: Jonas Ådahl >
> 
> 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
>>> 
>> +
>> +Calling this after an xdg_toplevel's first commit will raise a 
>> client error.
>> +  
>> +  
> 
> Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
> scanner handle
> this combination of array and enum correctly?
> 
> Good catch. This also affects the event above it.
 
 As we discussed via IRC (27 May), the scanner will choke on this. While we 
 talked about
 making a change to the scanner to allow this, perhaps such a change 
 doesn't make sense.
 
 Given a type="array", scanner will generate a parameter of type wl_array.
 
 Perhaps the short story here is to just remove the enum from this arg, and 
 the similar
 arg in the configure_draw_states event above. What do you think?
 
 (I wonder if it's the DTD that can change, so the scanner's validation step
 will catch the unsupported combination of type="array" enum="foo". My gut 
 tells me that
 DTDs don't support this logic, but I'll dig into this.)
>>> 
>>> Hi,
>>> 
>>> here is some background.
>>> 
>>> A type="array" argument is really just a binary blob of data. The XML
>>> description, human documentation aside, does not specify anything about
>>> the blob contents. Therefore adding an XML attribute pointing to an
>>> enum definition is half-useless. Generators could use it for creating
>>> automatic links in documentation, but it cannot be used for code
>>> generation, because you don't know the types contained in the blob.
>>> 
>>> We also do not want to add blob content type definitions to the XML
>>> language, because you might want to have everything C is able to
>>> express, including nested structs. There is also no requirement that
>>> the "array" is really an array - every "element" could be a different
>>> thing. It could be bitstream and whatnot. Only the use of
>>> wl_array_for_each() implies it is an array of similar elements,
>>> wl_array_add() does not.
>>> 
>>> The big point in adding enum annotations was that language bindings
>>> generators (other than wayland-scanner) could use the annotation for
>>> code generation. I don't think it is possible with the array type.
>>> 
>>> If we allow enum annotation with the array type, it will only be usable
>>> for doc links, unlike the other enum annotations.
>>> 
>>> OTOH, we have lots and lots of places in the documentation texts that
>>> refer to some request, event, interface, etc. that would be useful as a
>>> hyperlink in the generated docs. Enums could fall into that as well, so
>>> we would not need the attribute for only documentation.
>>> 
>>> Auke, Nils, what's your take on this matter?
>>> 
>>> We do have some documentation about enums in
>>> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
>>> 
>>> Thanks,
>>> pq
>> 
>> Pekka,
>> Thank you for the info. Just so I understand your points correctly, let
>> me assert that /just/ making a minor change to scanner to not error on
>> the presence of both array and enum together does not have any major
>> drawbacks.
>> 
>> Correct?
> 
> Technically, it might be the case that nothing will necessarily break
> *now*. But such a change would move us from very the currently
> well-defined semantics of the enum 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Auke Booij]

On 1 June 2016 at 20:16, Yong Bakos  wrote:
> On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
>>
>> On Sat, 28 May 2016 08:39:59 -0500
>> Yong Bakos  wrote:
>>
>>> Hi Mike,
>>> Regarding the combination of type="array" enum="foo"...
>>>
 On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
  wrote:

 I've inlined some replies below.

 On Fri, May 27, 2016 at 1:13 PM Yong Bakos > wrote:
 On May 27, 2016, at 10:29 AM, Mike Blumenkrantz > wrote:
>
> this adds a method for compositors to change various draw attributes
> for a surface
>
> Signed-off-by: Mike Blumenkrantz  >
> Signed-off-by: Jonas Ådahl >

 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
>>
> +
> +Calling this after an xdg_toplevel's first commit will raise a 
> client error.
> +  
> +  

 Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
 scanner handle
 this combination of array and enum correctly?

 Good catch. This also affects the event above it.
>>>
>>> As we discussed via IRC (27 May), the scanner will choke on this. While we 
>>> talked about
>>> making a change to the scanner to allow this, perhaps such a change doesn't 
>>> make sense.
>>>
>>> Given a type="array", scanner will generate a parameter of type wl_array.
>>>
>>> Perhaps the short story here is to just remove the enum from this arg, and 
>>> the similar
>>> arg in the configure_draw_states event above. What do you think?
>>>
>>> (I wonder if it's the DTD that can change, so the scanner's validation step
>>> will catch the unsupported combination of type="array" enum="foo". My gut 
>>> tells me that
>>> DTDs don't support this logic, but I'll dig into this.)
>>
>> Hi,
>>
>> here is some background.
>>
>> A type="array" argument is really just a binary blob of data. The XML
>> description, human documentation aside, does not specify anything about
>> the blob contents. Therefore adding an XML attribute pointing to an
>> enum definition is half-useless. Generators could use it for creating
>> automatic links in documentation, but it cannot be used for code
>> generation, because you don't know the types contained in the blob.
>>
>> We also do not want to add blob content type definitions to the XML
>> language, because you might want to have everything C is able to
>> express, including nested structs. There is also no requirement that
>> the "array" is really an array - every "element" could be a different
>> thing. It could be bitstream and whatnot. Only the use of
>> wl_array_for_each() implies it is an array of similar elements,
>> wl_array_add() does not.
>>
>> The big point in adding enum annotations was that language bindings
>> generators (other than wayland-scanner) could use the annotation for
>> code generation. I don't think it is possible with the array type.
>>
>> If we allow enum annotation with the array type, it will only be usable
>> for doc links, unlike the other enum annotations.
>>
>> OTOH, we have lots and lots of places in the documentation texts that
>> refer to some request, event, interface, etc. that would be useful as a
>> hyperlink in the generated docs. Enums could fall into that as well, so
>> we would not need the attribute for only documentation.
>>
>> Auke, Nils, what's your take on this matter?
>>
>> We do have some documentation about enums in
>> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
>>
>> Thanks,
>> pq
>
> Pekka,
> Thank you for the info. Just so I understand your points correctly, let
> me assert that /just/ making a minor change to scanner to not error on
> the presence of both array and enum together does not have any major
> drawbacks.
>
> Correct?

Technically, it might be the case that nothing will necessarily break
*now*. But such a change would move us from very the currently
well-defined semantics of the enum attribute, into weird
documentation-only or half-defined specifications. This will be
confusing more often than it will be helpful.

If you want to refer to a specific enum, because your binary data
*could* be interpreted 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Jonas Ådahl]

On Thu, Jun 02, 2016 at 11:30:41AM +0300, Pekka Paalanen wrote:
> On Thu, 2 Jun 2016 15:39:47 +0800
> Jonas Ådahl  wrote:
> 
> > On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:
> > > On Wed, 1 Jun 2016 13:16:31 -0500
> > > Yong Bakos  wrote:
> > >   
> > > > On May 30, 2016, at 3:54 AM, Pekka Paalanen  
> > > > wrote:  
> > > > > 
> > > > > On Sat, 28 May 2016 08:39:59 -0500
> > > > > Yong Bakos  wrote:
> > > > > 
> > > > >> Hi Mike,
> > > > >> Regarding the combination of type="array" enum="foo"...
> > > > >> 
> > > > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> > > > >>>  wrote:
> > > > >>> 
> > > > >>> I've inlined some replies below.
> > > > >>> 
> > > > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > > > >>> > wrote:
> > > > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
> > > > >>> > wrote:
> > > >  
> > > >  this adds a method for compositors to change various draw 
> > > >  attributes
> > > >  for a surface
> > > >  
> > > >  Signed-off-by: Mike Blumenkrantz  > > >  >
> > > >  Signed-off-by: Jonas Ådahl  > > >  >
> > > > >>> 
> > > > >>> 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
> > > > > 
> > > >  +
> > > >  +Calling this after an xdg_toplevel's first commit will 
> > > >  raise a client error.
> > > >  +  
> > > >  +  
> > > > >>> 
> > > > >>> Just a sanity check, since I haven't seen it in a protocol spec 
> > > > >>> yet. Does scanner handle
> > > > >>> this combination of array and enum correctly?
> > > > >>> 
> > > > >>> Good catch. This also affects the event above it.
> > > > >> 
> > > > >> As we discussed via IRC (27 May), the scanner will choke on this. 
> > > > >> While we talked about
> > > > >> making a change to the scanner to allow this, perhaps such a change 
> > > > >> doesn't make sense.
> > > > >> 
> > > > >> Given a type="array", scanner will generate a parameter of type 
> > > > >> wl_array.
> > > > >> 
> > > > >> Perhaps the short story here is to just remove the enum from this 
> > > > >> arg, and the similar
> > > > >> arg in the configure_draw_states event above. What do you think?
> > > > >> 
> > > > >> (I wonder if it's the DTD that can change, so the scanner's 
> > > > >> validation step
> > > > >> will catch the unsupported combination of type="array" enum="foo". 
> > > > >> My gut tells me that
> > > > >> DTDs don't support this logic, but I'll dig into this.)
> > > > > 
> > > > > Hi,
> > > > > 
> > > > > here is some background.
> > > > > 
> > > > > A type="array" argument is really just a binary blob of data. The XML
> > > > > description, human documentation aside, does not specify anything 
> > > > > about
> > > > > the blob contents. Therefore adding an XML attribute pointing to an
> > > > > enum definition is half-useless. Generators could use it for creating
> > > > > automatic links in documentation, but it cannot be used for code
> > > > > generation, because you don't know the types contained in the blob.
> > > > > 
> > > > > We also do not want to add blob content type definitions to the XML
> > > > > language, because you might want to have everything C is able to
> > > > > express, including nested structs. There is also no requirement that
> > > > > the "array" is really an array - every "element" could be a different
> > > > > thing. It could be bitstream and whatnot. Only the use of
> > > > > wl_array_for_each() implies it is an array of similar elements,
> > > > > wl_array_add() does not.
> > > > > 
> > > > > The big point in adding enum annotations was that language bindings
> > > > > generators (other than wayland-scanner) could use the annotation for
> > > > > code generation. I don't think it is possible with the array type.
> > > > > 
> > > > > If we allow enum annotation with the array type, it will only be 
> > > > > usable
> > > > > for doc links, unlike the other enum annotations.
> > > > > 
> > > > > OTOH, we have lots and lots of places in the documentation texts that
> 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Pekka Paalanen]

On Thu, 2 Jun 2016 15:39:47 +0800
Jonas Ådahl  wrote:

> On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:
> > On Wed, 1 Jun 2016 13:16:31 -0500
> > Yong Bakos  wrote:
> >   
> > > On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:  
> > > > 
> > > > On Sat, 28 May 2016 08:39:59 -0500
> > > > Yong Bakos  wrote:
> > > > 
> > > >> Hi Mike,
> > > >> Regarding the combination of type="array" enum="foo"...
> > > >> 
> > > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> > > >>>  wrote:
> > > >>> 
> > > >>> I've inlined some replies below.
> > > >>> 
> > > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > > >>> > wrote:
> > > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
> > > >>> > wrote:
> > >  
> > >  this adds a method for compositors to change various draw attributes
> > >  for a surface
> > >  
> > >  Signed-off-by: Mike Blumenkrantz  > >  >
> > >  Signed-off-by: Jonas Ådahl  > >  >
> > > >>> 
> > > >>> 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
> > > > 
> > >  +
> > >  +Calling this after an xdg_toplevel's first commit will 
> > >  raise a client error.
> > >  +  
> > >  +  
> > > >>> 
> > > >>> Just a sanity check, since I haven't seen it in a protocol spec yet. 
> > > >>> Does scanner handle
> > > >>> this combination of array and enum correctly?
> > > >>> 
> > > >>> Good catch. This also affects the event above it.
> > > >> 
> > > >> As we discussed via IRC (27 May), the scanner will choke on this. 
> > > >> While we talked about
> > > >> making a change to the scanner to allow this, perhaps such a change 
> > > >> doesn't make sense.
> > > >> 
> > > >> Given a type="array", scanner will generate a parameter of type 
> > > >> wl_array.
> > > >> 
> > > >> Perhaps the short story here is to just remove the enum from this arg, 
> > > >> and the similar
> > > >> arg in the configure_draw_states event above. What do you think?
> > > >> 
> > > >> (I wonder if it's the DTD that can change, so the scanner's validation 
> > > >> step
> > > >> will catch the unsupported combination of type="array" enum="foo". My 
> > > >> gut tells me that
> > > >> DTDs don't support this logic, but I'll dig into this.)
> > > > 
> > > > Hi,
> > > > 
> > > > here is some background.
> > > > 
> > > > A type="array" argument is really just a binary blob of data. The XML
> > > > description, human documentation aside, does not specify anything about
> > > > the blob contents. Therefore adding an XML attribute pointing to an
> > > > enum definition is half-useless. Generators could use it for creating
> > > > automatic links in documentation, but it cannot be used for code
> > > > generation, because you don't know the types contained in the blob.
> > > > 
> > > > We also do not want to add blob content type definitions to the XML
> > > > language, because you might want to have everything C is able to
> > > > express, including nested structs. There is also no requirement that
> > > > the "array" is really an array - every "element" could be a different
> > > > thing. It could be bitstream and whatnot. Only the use of
> > > > wl_array_for_each() implies it is an array of similar elements,
> > > > wl_array_add() does not.
> > > > 
> > > > The big point in adding enum annotations was that language bindings
> > > > generators (other than wayland-scanner) could use the annotation for
> > > > code generation. I don't think it is possible with the array type.
> > > > 
> > > > If we allow enum annotation with the array type, it will only be usable
> > > > for doc links, unlike the other enum annotations.
> > > > 
> > > > OTOH, we have lots and lots of places in the documentation texts that
> > > > refer to some request, event, interface, etc. that would be useful as a
> > > > hyperlink in the generated docs. Enums could fall into that as well, so
> > > > we would not need the attribute for only documentation.
> > > > 
> > > > Auke, Nils, what's your take on this matter?
> > > > 
> > > > We do have some 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Jonas Ådahl]

On Thu, Jun 02, 2016 at 10:24:19AM +0300, Pekka Paalanen wrote:
> On Wed, 1 Jun 2016 13:16:31 -0500
> Yong Bakos  wrote:
> 
> > On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
> > > 
> > > On Sat, 28 May 2016 08:39:59 -0500
> > > Yong Bakos  wrote:
> > >   
> > >> Hi Mike,
> > >> Regarding the combination of type="array" enum="foo"...
> > >>   
> > >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> > >>>  wrote:
> > >>> 
> > >>> I've inlined some replies below.
> > >>> 
> > >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > >>> > wrote:
> > >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  > >>> > wrote:  
> >  
> >  this adds a method for compositors to change various draw attributes
> >  for a surface
> >  
> >  Signed-off-by: Mike Blumenkrantz  >  >
> >  Signed-off-by: Jonas Ådahl  >  >  
> > >>> 
> > >>> 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  
> > >   
> >  +
> >  +Calling this after an xdg_toplevel's first commit will raise 
> >  a client error.
> >  +  
> >  +
> > >>> 
> > >>> Just a sanity check, since I haven't seen it in a protocol spec yet. 
> > >>> Does scanner handle
> > >>> this combination of array and enum correctly?
> > >>> 
> > >>> Good catch. This also affects the event above it.  
> > >> 
> > >> As we discussed via IRC (27 May), the scanner will choke on this. While 
> > >> we talked about
> > >> making a change to the scanner to allow this, perhaps such a change 
> > >> doesn't make sense.
> > >> 
> > >> Given a type="array", scanner will generate a parameter of type wl_array.
> > >> 
> > >> Perhaps the short story here is to just remove the enum from this arg, 
> > >> and the similar
> > >> arg in the configure_draw_states event above. What do you think?
> > >> 
> > >> (I wonder if it's the DTD that can change, so the scanner's validation 
> > >> step
> > >> will catch the unsupported combination of type="array" enum="foo". My 
> > >> gut tells me that
> > >> DTDs don't support this logic, but I'll dig into this.)  
> > > 
> > > Hi,
> > > 
> > > here is some background.
> > > 
> > > A type="array" argument is really just a binary blob of data. The XML
> > > description, human documentation aside, does not specify anything about
> > > the blob contents. Therefore adding an XML attribute pointing to an
> > > enum definition is half-useless. Generators could use it for creating
> > > automatic links in documentation, but it cannot be used for code
> > > generation, because you don't know the types contained in the blob.
> > > 
> > > We also do not want to add blob content type definitions to the XML
> > > language, because you might want to have everything C is able to
> > > express, including nested structs. There is also no requirement that
> > > the "array" is really an array - every "element" could be a different
> > > thing. It could be bitstream and whatnot. Only the use of
> > > wl_array_for_each() implies it is an array of similar elements,
> > > wl_array_add() does not.
> > > 
> > > The big point in adding enum annotations was that language bindings
> > > generators (other than wayland-scanner) could use the annotation for
> > > code generation. I don't think it is possible with the array type.
> > > 
> > > If we allow enum annotation with the array type, it will only be usable
> > > for doc links, unlike the other enum annotations.
> > > 
> > > OTOH, we have lots and lots of places in the documentation texts that
> > > refer to some request, event, interface, etc. that would be useful as a
> > > hyperlink in the generated docs. Enums could fall into that as well, so
> > > we would not need the attribute for only documentation.
> > > 
> > > Auke, Nils, what's your take on this matter?
> > > 
> > > We do have some documentation about enums in
> > > https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
> > > 
> > > Thanks,
> > > pq  
> > 
> > Pekka,
> > Thank you for the info. Just so I understand your points correctly, let
> > me assert that /just/ making a minor change to scanner to not error on
> > the 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Pekka Paalanen]

On Wed, 1 Jun 2016 13:16:31 -0500
Yong Bakos  wrote:

> On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
> > 
> > On Sat, 28 May 2016 08:39:59 -0500
> > Yong Bakos  wrote:
> >   
> >> Hi Mike,
> >> Regarding the combination of type="array" enum="foo"...
> >>   
> >>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> >>>  wrote:
> >>> 
> >>> I've inlined some replies below.
> >>> 
> >>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  >>> > wrote:
> >>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  >>> > wrote:  
>  
>  this adds a method for compositors to change various draw attributes
>  for a surface
>  
>  Signed-off-by: Mike Blumenkrantz   >
>  Signed-off-by: Jonas Ådahl >  
> >>> 
> >>> 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  
> >   
>  +
>  +Calling this after an xdg_toplevel's first commit will raise a 
>  client error.
>  +  
>  +
> >>> 
> >>> Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
> >>> scanner handle
> >>> this combination of array and enum correctly?
> >>> 
> >>> Good catch. This also affects the event above it.  
> >> 
> >> As we discussed via IRC (27 May), the scanner will choke on this. While we 
> >> talked about
> >> making a change to the scanner to allow this, perhaps such a change 
> >> doesn't make sense.
> >> 
> >> Given a type="array", scanner will generate a parameter of type wl_array.
> >> 
> >> Perhaps the short story here is to just remove the enum from this arg, and 
> >> the similar
> >> arg in the configure_draw_states event above. What do you think?
> >> 
> >> (I wonder if it's the DTD that can change, so the scanner's validation step
> >> will catch the unsupported combination of type="array" enum="foo". My gut 
> >> tells me that
> >> DTDs don't support this logic, but I'll dig into this.)  
> > 
> > Hi,
> > 
> > here is some background.
> > 
> > A type="array" argument is really just a binary blob of data. The XML
> > description, human documentation aside, does not specify anything about
> > the blob contents. Therefore adding an XML attribute pointing to an
> > enum definition is half-useless. Generators could use it for creating
> > automatic links in documentation, but it cannot be used for code
> > generation, because you don't know the types contained in the blob.
> > 
> > We also do not want to add blob content type definitions to the XML
> > language, because you might want to have everything C is able to
> > express, including nested structs. There is also no requirement that
> > the "array" is really an array - every "element" could be a different
> > thing. It could be bitstream and whatnot. Only the use of
> > wl_array_for_each() implies it is an array of similar elements,
> > wl_array_add() does not.
> > 
> > The big point in adding enum annotations was that language bindings
> > generators (other than wayland-scanner) could use the annotation for
> > code generation. I don't think it is possible with the array type.
> > 
> > If we allow enum annotation with the array type, it will only be usable
> > for doc links, unlike the other enum annotations.
> > 
> > OTOH, we have lots and lots of places in the documentation texts that
> > refer to some request, event, interface, etc. that would be useful as a
> > hyperlink in the generated docs. Enums could fall into that as well, so
> > we would not need the attribute for only documentation.
> > 
> > Auke, Nils, what's your take on this matter?
> > 
> > We do have some documentation about enums in
> > https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
> > 
> > Thanks,
> > pq  
> 
> Pekka,
> Thank you for the info. Just so I understand your points correctly, let
> me assert that /just/ making a minor change to scanner to not error on
> the presence of both array and enum together does not have any major
> drawbacks.

None other than it does not make sense now and I cannot see how it
could make sense in the future. I see it similar to allowing
"interface" attribute on  tags whose type is not "object" or
"new_id".

Therefore I am against the idea 

Re: array and enum attributes (Was: [PATCH] xdg-shell: add draw states for xdg_surface)

[Yong Bakos]

On May 30, 2016, at 3:54 AM, Pekka Paalanen  wrote:
> 
> On Sat, 28 May 2016 08:39:59 -0500
> Yong Bakos  wrote:
> 
>> Hi Mike,
>> Regarding the combination of type="array" enum="foo"...
>> 
>>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>>>  wrote:
>>> 
>>> I've inlined some replies below.
>>> 
>>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos >> > wrote:
>>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz >> > wrote:
 
 this adds a method for compositors to change various draw attributes
 for a surface
 
 Signed-off-by: Mike Blumenkrantz >
 Signed-off-by: Jonas Ådahl >
>>> 
>>> 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
> 
 +
 +Calling this after an xdg_toplevel's first commit will raise a 
 client error.
 +  
 +  
>>> 
>>> Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
>>> scanner handle
>>> this combination of array and enum correctly?
>>> 
>>> Good catch. This also affects the event above it.
>> 
>> As we discussed via IRC (27 May), the scanner will choke on this. While we 
>> talked about
>> making a change to the scanner to allow this, perhaps such a change doesn't 
>> make sense.
>> 
>> Given a type="array", scanner will generate a parameter of type wl_array.
>> 
>> Perhaps the short story here is to just remove the enum from this arg, and 
>> the similar
>> arg in the configure_draw_states event above. What do you think?
>> 
>> (I wonder if it's the DTD that can change, so the scanner's validation step
>> will catch the unsupported combination of type="array" enum="foo". My gut 
>> tells me that
>> DTDs don't support this logic, but I'll dig into this.)
> 
> Hi,
> 
> here is some background.
> 
> A type="array" argument is really just a binary blob of data. The XML
> description, human documentation aside, does not specify anything about
> the blob contents. Therefore adding an XML attribute pointing to an
> enum definition is half-useless. Generators could use it for creating
> automatic links in documentation, but it cannot be used for code
> generation, because you don't know the types contained in the blob.
> 
> We also do not want to add blob content type definitions to the XML
> language, because you might want to have everything C is able to
> express, including nested structs. There is also no requirement that
> the "array" is really an array - every "element" could be a different
> thing. It could be bitstream and whatnot. Only the use of
> wl_array_for_each() implies it is an array of similar elements,
> wl_array_add() does not.
> 
> The big point in adding enum annotations was that language bindings
> generators (other than wayland-scanner) could use the annotation for
> code generation. I don't think it is possible with the array type.
> 
> If we allow enum annotation with the array type, it will only be usable
> for doc links, unlike the other enum annotations.
> 
> OTOH, we have lots and lots of places in the documentation texts that
> refer to some request, event, interface, etc. that would be useful as a
> hyperlink in the generated docs. Enums could fall into that as well, so
> we would not need the attribute for only documentation.
> 
> Auke, Nils, what's your take on this matter?
> 
> We do have some documentation about enums in
> https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles
> 
> Thanks,
> pq

Pekka,
Thank you for the info. Just so I understand your points correctly, let
me assert that /just/ making a minor change to scanner to not error on
the presence of both array and enum together does not have any major
drawbacks.

Correct?

Thank you,
yong



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

[Benoit Gschwind]

Hello Derek,

Maybe I fail to explain my point of view:

I propose to have only one state array, I also propose that client
provide hints about which optional state he support. This is somehow
similar to EWMH - _NET_WM_STATE and EWMH - _NET_WM_ALLOWED_ACTIONS
respectively.

my arguments are:
 - state flags and draw flags are the same things, even if they look
different.
 - separating optionals and mandatory state has no benefit, the client
and the compositor can ignore them, even if they are mandatory.
consequently that make them /de facto/ optional. I do not mean it's a
good things, I mean separating them does not improve the situation.
Keeping them together just avoid long discussion on which side they must
go state or drawing state?

On 31/05/2016 23:04, Derek Foreman wrote:
> On 31/05/16 02:31 PM, Benoit Gschwind wrote:
>> Hello mike,
>>
>> Thank for your clarification, I try to summarize the issue/need:
>>
>> A compositor may want to draw a client without the shadow. In particular
>> if the window is integrated to a GUI component, I can imagine tilling.
> 
> Tiling seems only tangentially related to this proposal, since it's just
> one reason why a compositor might want to turn off drop shadows.
> 

Just tried to get a tangible definition of the issue/need to not discuss
hypothetical cases.

>> Taking your issue, the drawing state look very similar to the state
>> flags. You wrote: "[the draw state is] specifically related to drawing
>> only". Actually, removing the shadow may have side effect related to
>> behavior, in particular for client that use shadow as resize handlers,
> 
> The spec mentions that removing the drop shadow may interfere with
> interactive resize - from my reading it seems the intent is just to tell
> the client not to render drop shadows (not to draw something else in
> their place).  Perhaps that could be clarified in the next revision.
> 

My intension wasn't to get this clarified ;)

>> those client may replace shadow by plain borders. In that case the
>> difference is very thin. In the oposite way, the most expected changes
>> of fullscreen or maximized state is the client layout.
>>
>> You wrote: "[the draw state has] negotiation", I agree, but I will use
>> the wording "hint" because look more appropriate. Why do not add state
>> hint ? Some will argue that state are mandatory, to that I reply: ok,
>> how do you enforce it? You have no way to check that a client do not
>> draw a shadow while maximized or in fullscreen state, or basically
>> ignore the state. Thus just consider that those mandatory hints are
>> always included. States hints are similar to EWMH [1] or the WM_PROTOCOL
>> of ICCCM.
> 
> I'm not sure I understand your point, but I think you just successfully
> shot it down yourself?
> 

I don't know where I shot myself, I re-explained my point of view above.

> Moving right along then... ;)
> 
> Indeed states are mandatory and the compositor has to assume they've
> been obeyed - any app that doesn't is buggy.  Adding optional behaviour
> to that mechanism seems like a really bad idea.
> 

Please add arguments why it is a bad idea, I don't see why. The proposal
was basically to add optional drawing states. I do not see why optional
drawing states is better idea than optional states, moreover, I do not
see the *real* difference between states and drawing states.

> The negotiated method presented here seems less bug prone, and allowing
> toolkits not to have to implement all states seems less onerous.
> 

This match my proposal, but it look like I failed to explain it
properly. Or maybe I misunderstood the proposal.

> PS: When we're done re-inventing EWMH for wayland, can we have xatoms
> too?  Hmm, maybe not everything from the old days needs a direct mapping
> to wayland. :)

I agree, and the opposite apply, not all old stuff are broken. Analyzing
old stuff and picking what working save time. In that particular case I
do not say please add vertical_maximized state, I just says the old
stuff did the job and I propose a similar things, thus it's not insane,
thus please consider it as an (better) alternative.

Best regards,
Benoit Gschwind

> Thanks,
> Derek
> 
>> About the state enum, you are correct, the current spec. has reserved
>> ranges. My opinion still the same, this ranges are basically anti-standard.
>>
>> Best regards.
>>
>> [1]
>> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792
>>
>> On 31/05/2016 17:40, Mike Blumenkrantz wrote:
>>> 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 

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

[Derek Foreman]

On 31/05/16 02:31 PM, Benoit Gschwind wrote:
> Hello mike,
> 
> Thank for your clarification, I try to summarize the issue/need:
> 
> A compositor may want to draw a client without the shadow. In particular
> if the window is integrated to a GUI component, I can imagine tilling.

Tiling seems only tangentially related to this proposal, since it's just
one reason why a compositor might want to turn off drop shadows.

> Taking your issue, the drawing state look very similar to the state
> flags. You wrote: "[the draw state is] specifically related to drawing
> only". Actually, removing the shadow may have side effect related to
> behavior, in particular for client that use shadow as resize handlers,

The spec mentions that removing the drop shadow may interfere with
interactive resize - from my reading it seems the intent is just to tell
the client not to render drop shadows (not to draw something else in
their place).  Perhaps that could be clarified in the next revision.

> those client may replace shadow by plain borders. In that case the
> difference is very thin. In the oposite way, the most expected changes
> of fullscreen or maximized state is the client layout.
> 
> You wrote: "[the draw state has] negotiation", I agree, but I will use
> the wording "hint" because look more appropriate. Why do not add state
> hint ? Some will argue that state are mandatory, to that I reply: ok,
> how do you enforce it? You have no way to check that a client do not
> draw a shadow while maximized or in fullscreen state, or basically
> ignore the state. Thus just consider that those mandatory hints are
> always included. States hints are similar to EWMH [1] or the WM_PROTOCOL
> of ICCCM.

I'm not sure I understand your point, but I think you just successfully
shot it down yourself?

Moving right along then... ;)

Indeed states are mandatory and the compositor has to assume they've
been obeyed - any app that doesn't is buggy.  Adding optional behaviour
to that mechanism seems like a really bad idea.

The negotiated method presented here seems less bug prone, and allowing
toolkits not to have to implement all states seems less onerous.

PS: When we're done re-inventing EWMH for wayland, can we have xatoms
too?  Hmm, maybe not everything from the old days needs a direct mapping
to wayland. :)

Thanks,
Derek

> About the state enum, you are correct, the current spec. has reserved
> ranges. My opinion still the same, this ranges are basically anti-standard.
> 
> Best regards.
> 
> [1]
> https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792
> 
> On 31/05/2016 17:40, Mike Blumenkrantz wrote:
>> 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 

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

[Benoit Gschwind]

Hello mike,

Thank for your clarification, I try to summarize the issue/need:

A compositor may want to draw a client without the shadow. In particular
if the window is integrated to a GUI component, I can imagine tilling.

Taking your issue, the drawing state look very similar to the state
flags. You wrote: "[the draw state is] specifically related to drawing
only". Actually, removing the shadow may have side effect related to
behavior, in particular for client that use shadow as resize handlers,
those client may replace shadow by plain borders. In that case the
difference is very thin. In the oposite way, the most expected changes
of fullscreen or maximized state is the client layout.

You wrote: "[the draw state has] negotiation", I agree, but I will use
the wording "hint" because look more appropriate. Why do not add state
hint ? Some will argue that state are mandatory, to that I reply: ok,
how do you enforce it? You have no way to check that a client do not
draw a shadow while maximized or in fullscreen state, or basically
ignore the state. Thus just consider that those mandatory hints are
always included. States hints are similar to EWMH [1] or the WM_PROTOCOL
of ICCCM.

About the state enum, you are correct, the current spec. has reserved
ranges. My opinion still the same, this ranges are basically anti-standard.

Best regards.

[1]
https://specifications.freedesktop.org/wm-spec/wm-spec-latest.html#idm140200472593792

On 31/05/2016 17:40, Mike Blumenkrantz wrote:
> 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]

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

[Olivier Fourdan]

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

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

[Jonas Ådahl]

On Tue, May 31, 2016 at 05:24:35AM -0400, Olivier Fourdan wrote:
> Hey
> 
> Just to make it clear, as a foreword to my comments inline below, I am not 
> against the patch, far from it, I just wanted to make sure we considered edge 
> values instead of only "no shadow", and we also considered other draw states.
> 
> 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.

> 
> For reference, this reminds me of the windows' semantics in EWMH. Before 
> EWMH, apps would use Motif MWM hints to specify if they wanted to have 
> borders, title, buttons, etc. With EWMH, apps would rather advertise a type 
> of window (dialog, menu, etc.), and the WM would decide how to decorate them, 
> so it would be a lot more consistent between apps. I still prefer the EWMH 
> approach to the MWM hints ^_~
> 
> Back to the topic...
> 
> - Original Message -
> > On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
> > > Hello Jonas, Mike and Olivier,
> > > 
> > > [...]
> > > > I see nothing wrong with it in a separate (optional) protocol for
> > > > experimenting, but as soon as we have clients and compositors using
> > > > private values out in the field, it might become harder to put things
> > > > back into the agreed standard set.
> > 
> > I don't see why. We either have two integer values meaning the same
> > thing (the "upstreamed" number, and the private), or we have an
> > upstreamed integer part of the xdg_ and a private integer part of a
> > separate protocol.
> > 
> > The "upstreaming" procedure would be identical anyhow: writing a patch
> > adding the new entry to the enum.
> 
> No, for private ranges, no patch is needed as the values are private and do 
> not need to be documented in the standard. 
> 
> I think it's the sore point, having undocumented, private values in a 
> standard.

As said in the other mail, personally I'd be fine with dropping range
allocation and requiring toolkits etc to add their own enums and
configure events.

> 
> > Either way, semantically, the result will be identical. Personally I
> > don't care much whether per DE state enum entry allocations are to be
> > the current way or or in an extensions really with its own configure
> > event. Removing alloctions it from xdg_ would only an inconvenience to
> > do the exact same thing.
> > 
> > Just to repeat, the purpose of range allocations is to DE:s to make use
> > of the already present configure/ack_configure and now set_available_...
> > parts, but with their own private (not part of xdg_) integers, without
> > the issues of introducing any incompatibilities with other toolkits and
> > compositors. None of these private entries would ever be added or
> > referenced in xdg_shell.
> 
> Precisely, the point is that it defeats the purpose of a "standard" which is, 
> by definition, aimed to be shared between different implementations.
> 
> > > At the moment, You proposal just address the issue of the shadow, thus a
> > > simple set_no_shadow event should be enough ?
> > 
> > The reason for having a "draw state" besides "window state" (the state
> > we already have) is so that we have one state that is properly
> > negotiated. The window state is not negotiated; a compositor will just
> > add states it thinks the client should know about, but doesn't care much
> > whether the client changed its drawing in any way.
> > 
> > For draw states, the purpose of adding an entry is for when the
> > compositor actually cares. Shadows is one such thing, because as far as
> > I know for example KDE intends to draw its own server side shadows, and
> > could use a "no shadow" draw state to figure out whether it is possible.
> 
> OMG SSD! :) In this case you'd need "no border" and "no title bar" as well.

I imagine such entries could be added to the draw state enum indeed. I
also will assume such entries will stay unused by for example the
default weston desktop shell and mutter, but thats another story.


Jonas
___
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

[Jonas Ådahl]

On Tue, May 31, 2016 at 11:16:51AM +0200, Benoit Gschwind wrote:
> 
> 
> On 31/05/2016 10:53, Jonas Ådahl wrote:
> > On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
> >> Hello Jonas, Mike and Olivier,
> >>
> >> On 30/05/2016 15:09, Olivier Fourdan wrote:
> >>> Hi Jonas,
> >>>
> >>> - Original Message -
>  On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
> >
> > Do we really want reserved ranges here?
> >
> > Some people reckon having (undocumented) reserved ranges was a bad idea 
> > in
> > "states", I wonder if we should redo this here again.
> >
> > Undocumented states from the reserved range are unlikely to be adopted 
> > by
> > other desktops, and that might lead to duplication of similar mechanisms
> > with different values.
> 
>  The purpose of a private range is not to have its values adopted by
>  other desktop environments, but rather a place to put experimental
>  things or things that might not suite a proper documented state. The
>  ranges is intended so that different DE:s don't conflict.
> 
>  I don't see what is wrong with that.
> >>>
> >>> I see nothing wrong with it in a separate (optional) protocol for 
> >>> experimenting, but as soon as we have clients and compositors using 
> >>> private values out in the field, it might become harder to put things 
> >>> back into the agreed standard set. 
> > 
> > I don't see why. We either have two integer values meaning the same
> > thing (the "upstreamed" number, and the private), or we have an
> > upstreamed integer part of the xdg_ and a private integer part of a
> > separate protocol.
> > 
> > The "upstreaming" procedure would be identical anyhow: writing a patch
> > adding the new entry to the enum.
> > 
> >>>
> >>
> >> Here I agree Olivier for this point, my argue is that xdg intend to
> >> provide a standard, and anyone expect that every DE follow this
> >> standard, thus each flags must be well defined and acknowledged. Any
> >> custom flags must fall in extension, that are not under the umbrella of 
> >> xdg.
> > 
> > Either way, semantically, the result will be identical. Personally I
> > don't care much whether per DE state enum entry allocations are to be
> > the current way or or in an extensions really with its own configure
> > event. Removing alloctions it from xdg_ would only an inconvenience to
> > do the exact same thing.
> 
> This is intended here, make difficult the wrong things, in our case
> custom states, make easier the proper things, in our case, following
> standard cases.
> 
> Thus the convenience argument here work against the standard we trying
> to bring to the community.

I see your point. I'll ack a patch that drops range allocation. It'd
probably need an ack from Mike as well, since I think they
(Enlightenment) have been one of the user of such a range.

> 
> > 
> > Just to repeat, the purpose of range allocations is to DE:s to make use
> > of the already present configure/ack_configure and now set_available_...
> > parts, but with their own private (not part of xdg_) integers, without
> > the issues of introducing any incompatibilities with other toolkits and
> > compositors. None of these private entries would ever be added or
> > referenced in xdg_shell.
> > 
> >>
> >> At the moment, You proposal just address the issue of the shadow, thus a
> >> simple set_no_shadow event should be enough ?
> > 
> > The reason for having a "draw state" besides "window state" (the state
> > we already have) is so that we have one state that is properly
> > negotiated. The window state is not negotiated; a compositor will just
> > add states it thinks the client should know about, but doesn't care much
> > whether the client changed its drawing in any way.
> > 
> > For draw states, the purpose of adding an entry is for when the
> > compositor actually cares. Shadows is one such thing, because as far as
> > I know for example KDE intends to draw its own server side shadows, and
> > could use a "no shadow" draw state to figure out whether it is possible.
> > 
> >>
>  The alternative is to have a separate configure event in an extension.
>  It would work the same way, is a bit more code to write, but it'd
>  effectively result in the same problem.
> >
> >> +  
> >> +
> >> +  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.
> >> +
> >> +  
> >> +
> >
> > Is a single "no shadow" state enough, isn't that too restrictive? If we 
> > put
> > this in perspective with a "tiled" state where we consider having
> > tiled_left/right/top/bottom, similarly, we could have "no_shadow_left",
> > 

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

[Benoit Gschwind]

Hello,

Just a reply to EWMH/MOTIF comments,

EWMH semantic is the path already started within xdg, as far as remember
v6 have toplevel, popup and tooltips surfaces, and will probably have
many more in the future.

That why we need a description of the issue we trying to solve. I can
assume that the issue is about toplevel window or not, thus should be a
flags list per surface role ?

Thinking about the proposal, and guessing the underlying issue, I
figured out that drawing request is the proper choice, even if it
introduce the trashed motif hint [1], and it is justified, because
compositor may want draw toplevel window in different manner. But at the
moment I see only one case that is for draw_without_shadow, but we can
easily drift to draw_tiled_mode, draw_glued_left, draw_glued_top,
draw_glued_right, draw_moving, draw_while_wobbling. In the case of drop
down menu: draw_span_left, draw_span_top, draw_without_shadow ? Once
again please define the issue.

I'm not against this proposal, but in current shape it does not comply
my requirement to include it as "a standard that any DE will have to
implement".

My opinion does not weight a lot anyway.

Best regards

[1] Side note: funnily, still implemented by all X11 WM, because EWMH
does not allow clients to declare that they draw their own borders.

On 31/05/2016 11:24, Olivier Fourdan wrote:
> Hey
> 
> Just to make it clear, as a foreword to my comments inline below, I am not 
> against the patch, far from it, I just wanted to make sure we considered edge 
> values instead of only "no shadow", and we also considered other draw states.
> 
> If we considered and dismissed them, fine.
> 
> For reference, this reminds me of the windows' semantics in EWMH. Before 
> EWMH, apps would use Motif MWM hints to specify if they wanted to have 
> borders, title, buttons, etc. With EWMH, apps would rather advertise a type 
> of window (dialog, menu, etc.), and the WM would decide how to decorate them, 
> so it would be a lot more consistent between apps. I still prefer the EWMH 
> approach to the MWM hints ^_~
> 
> Back to the topic...
> 
> - Original Message -
>> On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
>>> Hello Jonas, Mike and Olivier,
>>>
>>> [...]
 I see nothing wrong with it in a separate (optional) protocol for
 experimenting, but as soon as we have clients and compositors using
 private values out in the field, it might become harder to put things
 back into the agreed standard set.
>>
>> I don't see why. We either have two integer values meaning the same
>> thing (the "upstreamed" number, and the private), or we have an
>> upstreamed integer part of the xdg_ and a private integer part of a
>> separate protocol.
>>
>> The "upstreaming" procedure would be identical anyhow: writing a patch
>> adding the new entry to the enum.
> 
> No, for private ranges, no patch is needed as the values are private and do 
> not need to be documented in the standard. 
> 
> I think it's the sore point, having undocumented, private values in a 
> standard.
> 
>> Either way, semantically, the result will be identical. Personally I
>> don't care much whether per DE state enum entry allocations are to be
>> the current way or or in an extensions really with its own configure
>> event. Removing alloctions it from xdg_ would only an inconvenience to
>> do the exact same thing.
>>
>> Just to repeat, the purpose of range allocations is to DE:s to make use
>> of the already present configure/ack_configure and now set_available_...
>> parts, but with their own private (not part of xdg_) integers, without
>> the issues of introducing any incompatibilities with other toolkits and
>> compositors. None of these private entries would ever be added or
>> referenced in xdg_shell.
> 
> Precisely, the point is that it defeats the purpose of a "standard" which is, 
> by definition, aimed to be shared between different implementations.
> 
>>> At the moment, You proposal just address the issue of the shadow, thus a
>>> simple set_no_shadow event should be enough ?
>>
>> The reason for having a "draw state" besides "window state" (the state
>> we already have) is so that we have one state that is properly
>> negotiated. The window state is not negotiated; a compositor will just
>> add states it thinks the client should know about, but doesn't care much
>> whether the client changed its drawing in any way.
>>
>> For draw states, the purpose of adding an entry is for when the
>> compositor actually cares. Shadows is one such thing, because as far as
>> I know for example KDE intends to draw its own server side shadows, and
>> could use a "no shadow" draw state to figure out whether it is possible.
> 
> OMG SSD! :) In this case you'd need "no border" and "no title bar" as well.
> 
>>> This last comments look to overlap with some already existing feature
>>> within the protocol, I think about the input shape.
>>
>> Not sure how this has anything to do with input 

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

[Olivier Fourdan]

Hey

Just to make it clear, as a foreword to my comments inline below, I am not 
against the patch, far from it, I just wanted to make sure we considered edge 
values instead of only "no shadow", and we also considered other draw states.

If we considered and dismissed them, fine.

For reference, this reminds me of the windows' semantics in EWMH. Before EWMH, 
apps would use Motif MWM hints to specify if they wanted to have borders, 
title, buttons, etc. With EWMH, apps would rather advertise a type of window 
(dialog, menu, etc.), and the WM would decide how to decorate them, so it would 
be a lot more consistent between apps. I still prefer the EWMH approach to the 
MWM hints ^_~

Back to the topic...

- Original Message -
> On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
> > Hello Jonas, Mike and Olivier,
> > 
> > [...]
> > > I see nothing wrong with it in a separate (optional) protocol for
> > > experimenting, but as soon as we have clients and compositors using
> > > private values out in the field, it might become harder to put things
> > > back into the agreed standard set.
> 
> I don't see why. We either have two integer values meaning the same
> thing (the "upstreamed" number, and the private), or we have an
> upstreamed integer part of the xdg_ and a private integer part of a
> separate protocol.
> 
> The "upstreaming" procedure would be identical anyhow: writing a patch
> adding the new entry to the enum.

No, for private ranges, no patch is needed as the values are private and do not 
need to be documented in the standard. 

I think it's the sore point, having undocumented, private values in a standard.

> Either way, semantically, the result will be identical. Personally I
> don't care much whether per DE state enum entry allocations are to be
> the current way or or in an extensions really with its own configure
> event. Removing alloctions it from xdg_ would only an inconvenience to
> do the exact same thing.
> 
> Just to repeat, the purpose of range allocations is to DE:s to make use
> of the already present configure/ack_configure and now set_available_...
> parts, but with their own private (not part of xdg_) integers, without
> the issues of introducing any incompatibilities with other toolkits and
> compositors. None of these private entries would ever be added or
> referenced in xdg_shell.

Precisely, the point is that it defeats the purpose of a "standard" which is, 
by definition, aimed to be shared between different implementations.

> > At the moment, You proposal just address the issue of the shadow, thus a
> > simple set_no_shadow event should be enough ?
> 
> The reason for having a "draw state" besides "window state" (the state
> we already have) is so that we have one state that is properly
> negotiated. The window state is not negotiated; a compositor will just
> add states it thinks the client should know about, but doesn't care much
> whether the client changed its drawing in any way.
> 
> For draw states, the purpose of adding an entry is for when the
> compositor actually cares. Shadows is one such thing, because as far as
> I know for example KDE intends to draw its own server side shadows, and
> could use a "no shadow" draw state to figure out whether it is possible.

OMG SSD! :) In this case you'd need "no border" and "no title bar" as well.

> > This last comments look to overlap with some already existing feature
> > within the protocol, I think about the input shape.
> 
> Not sure how this has anything to do with input shapes.

True, I really meant fat borders, as in weston-terminal for example, not input 
shapes.

Cheers,
Olivier
___
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

[Benoit Gschwind]

On 31/05/2016 10:53, Jonas Ådahl wrote:
> On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
>> Hello Jonas, Mike and Olivier,
>>
>> On 30/05/2016 15:09, Olivier Fourdan wrote:
>>> Hi Jonas,
>>>
>>> - Original Message -
 On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
>
> Do we really want reserved ranges here?
>
> Some people reckon having (undocumented) reserved ranges was a bad idea in
> "states", I wonder if we should redo this here again.
>
> Undocumented states from the reserved range are unlikely to be adopted by
> other desktops, and that might lead to duplication of similar mechanisms
> with different values.

 The purpose of a private range is not to have its values adopted by
 other desktop environments, but rather a place to put experimental
 things or things that might not suite a proper documented state. The
 ranges is intended so that different DE:s don't conflict.

 I don't see what is wrong with that.
>>>
>>> I see nothing wrong with it in a separate (optional) protocol for 
>>> experimenting, but as soon as we have clients and compositors using private 
>>> values out in the field, it might become harder to put things back into the 
>>> agreed standard set. 
> 
> I don't see why. We either have two integer values meaning the same
> thing (the "upstreamed" number, and the private), or we have an
> upstreamed integer part of the xdg_ and a private integer part of a
> separate protocol.
> 
> The "upstreaming" procedure would be identical anyhow: writing a patch
> adding the new entry to the enum.
> 
>>>
>>
>> Here I agree Olivier for this point, my argue is that xdg intend to
>> provide a standard, and anyone expect that every DE follow this
>> standard, thus each flags must be well defined and acknowledged. Any
>> custom flags must fall in extension, that are not under the umbrella of xdg.
> 
> Either way, semantically, the result will be identical. Personally I
> don't care much whether per DE state enum entry allocations are to be
> the current way or or in an extensions really with its own configure
> event. Removing alloctions it from xdg_ would only an inconvenience to
> do the exact same thing.

This is intended here, make difficult the wrong things, in our case
custom states, make easier the proper things, in our case, following
standard cases.

Thus the convenience argument here work against the standard we trying
to bring to the community.

> 
> Just to repeat, the purpose of range allocations is to DE:s to make use
> of the already present configure/ack_configure and now set_available_...
> parts, but with their own private (not part of xdg_) integers, without
> the issues of introducing any incompatibilities with other toolkits and
> compositors. None of these private entries would ever be added or
> referenced in xdg_shell.
> 
>>
>> At the moment, You proposal just address the issue of the shadow, thus a
>> simple set_no_shadow event should be enough ?
> 
> The reason for having a "draw state" besides "window state" (the state
> we already have) is so that we have one state that is properly
> negotiated. The window state is not negotiated; a compositor will just
> add states it thinks the client should know about, but doesn't care much
> whether the client changed its drawing in any way.
> 
> For draw states, the purpose of adding an entry is for when the
> compositor actually cares. Shadows is one such thing, because as far as
> I know for example KDE intends to draw its own server side shadows, and
> could use a "no shadow" draw state to figure out whether it is possible.
> 
>>
 The alternative is to have a separate configure event in an extension.
 It would work the same way, is a bit more code to write, but it'd
 effectively result in the same problem.
>
>> +  
>> +
>> +  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.
>> +
>> +  
>> +
>
> Is a single "no shadow" state enough, isn't that too restrictive? If we 
> put
> this in perspective with a "tiled" state where we consider having
> tiled_left/right/top/bottom, similarly, we could have "no_shadow_left",
> "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would
> give a finer granularity.

 I think we should just add such tiling states to the window state enum,
 rather than the draw state. The only point with putting things in the
 draw state enum is to get the negotiation, while tiled vs not tiled is
 closer to maximized vs not maximized, i.e. a compositor wouldn't change
 its behaviour if the client couldn't not draw itself "tiled" or not.
>>>
>>> Sorry, I 

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

[Jonas Ådahl]

On Tue, May 31, 2016 at 10:31:28AM +0200, Benoit Gschwind wrote:
> Hello Jonas, Mike and Olivier,
> 
> On 30/05/2016 15:09, Olivier Fourdan wrote:
> > Hi Jonas,
> > 
> > - Original Message -
> >> On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
> >>>
> >>> Do we really want reserved ranges here?
> >>>
> >>> Some people reckon having (undocumented) reserved ranges was a bad idea in
> >>> "states", I wonder if we should redo this here again.
> >>>
> >>> Undocumented states from the reserved range are unlikely to be adopted by
> >>> other desktops, and that might lead to duplication of similar mechanisms
> >>> with different values.
> >>
> >> The purpose of a private range is not to have its values adopted by
> >> other desktop environments, but rather a place to put experimental
> >> things or things that might not suite a proper documented state. The
> >> ranges is intended so that different DE:s don't conflict.
> >>
> >> I don't see what is wrong with that.
> > 
> > I see nothing wrong with it in a separate (optional) protocol for 
> > experimenting, but as soon as we have clients and compositors using private 
> > values out in the field, it might become harder to put things back into the 
> > agreed standard set. 

I don't see why. We either have two integer values meaning the same
thing (the "upstreamed" number, and the private), or we have an
upstreamed integer part of the xdg_ and a private integer part of a
separate protocol.

The "upstreaming" procedure would be identical anyhow: writing a patch
adding the new entry to the enum.

> > 
> 
> Here I agree Olivier for this point, my argue is that xdg intend to
> provide a standard, and anyone expect that every DE follow this
> standard, thus each flags must be well defined and acknowledged. Any
> custom flags must fall in extension, that are not under the umbrella of xdg.

Either way, semantically, the result will be identical. Personally I
don't care much whether per DE state enum entry allocations are to be
the current way or or in an extensions really with its own configure
event. Removing alloctions it from xdg_ would only an inconvenience to
do the exact same thing.

Just to repeat, the purpose of range allocations is to DE:s to make use
of the already present configure/ack_configure and now set_available_...
parts, but with their own private (not part of xdg_) integers, without
the issues of introducing any incompatibilities with other toolkits and
compositors. None of these private entries would ever be added or
referenced in xdg_shell.

> 
> At the moment, You proposal just address the issue of the shadow, thus a
> simple set_no_shadow event should be enough ?

The reason for having a "draw state" besides "window state" (the state
we already have) is so that we have one state that is properly
negotiated. The window state is not negotiated; a compositor will just
add states it thinks the client should know about, but doesn't care much
whether the client changed its drawing in any way.

For draw states, the purpose of adding an entry is for when the
compositor actually cares. Shadows is one such thing, because as far as
I know for example KDE intends to draw its own server side shadows, and
could use a "no shadow" draw state to figure out whether it is possible.

> 
> >> The alternative is to have a separate configure event in an extension.
> >> It would work the same way, is a bit more code to write, but it'd
> >> effectively result in the same problem.
> >>>
>  +  
>  +
>  +  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.
>  +
>  +  
>  +
> >>>
> >>> Is a single "no shadow" state enough, isn't that too restrictive? If we 
> >>> put
> >>> this in perspective with a "tiled" state where we consider having
> >>> tiled_left/right/top/bottom, similarly, we could have "no_shadow_left",
> >>> "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would
> >>> give a finer granularity.
> >>
> >> I think we should just add such tiling states to the window state enum,
> >> rather than the draw state. The only point with putting things in the
> >> draw state enum is to get the negotiation, while tiled vs not tiled is
> >> closer to maximized vs not maximized, i.e. a compositor wouldn't change
> >> its behaviour if the client couldn't not draw itself "tiled" or not.
> > 
> > Sorry, I did not make myself clear, I was not asking for tiling to a be a 
> > draw state.
> > 
> >> As discussed in the bug you linked, there might be more to tiling than
> >> shadow as well; it might effect rounded-ness of corners and maybe other
> >> things as well, and adding "no_shadow_right" wouldn't address that.
> > 
> > No I was taking tiling as an example where we'd 

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

[Benoit Gschwind]

Hello Jonas, Mike and Olivier,

On 30/05/2016 15:09, Olivier Fourdan wrote:
> Hi Jonas,
> 
> - Original Message -
>> On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
>>>
>>> Do we really want reserved ranges here?
>>>
>>> Some people reckon having (undocumented) reserved ranges was a bad idea in
>>> "states", I wonder if we should redo this here again.
>>>
>>> Undocumented states from the reserved range are unlikely to be adopted by
>>> other desktops, and that might lead to duplication of similar mechanisms
>>> with different values.
>>
>> The purpose of a private range is not to have its values adopted by
>> other desktop environments, but rather a place to put experimental
>> things or things that might not suite a proper documented state. The
>> ranges is intended so that different DE:s don't conflict.
>>
>> I don't see what is wrong with that.
> 
> I see nothing wrong with it in a separate (optional) protocol for 
> experimenting, but as soon as we have clients and compositors using private 
> values out in the field, it might become harder to put things back into the 
> agreed standard set. 
> 

Here I agree Olivier for this point, my argue is that xdg intend to
provide a standard, and anyone expect that every DE follow this
standard, thus each flags must be well defined and acknowledged. Any
custom flags must fall in extension, that are not under the umbrella of xdg.

At the moment, You proposal just address the issue of the shadow, thus a
simple set_no_shadow event should be enough ?

>> The alternative is to have a separate configure event in an extension.
>> It would work the same way, is a bit more code to write, but it'd
>> effectively result in the same problem.
>>>
 +  
 +
 +  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.
 +
 +  
 +
>>>
>>> Is a single "no shadow" state enough, isn't that too restrictive? If we put
>>> this in perspective with a "tiled" state where we consider having
>>> tiled_left/right/top/bottom, similarly, we could have "no_shadow_left",
>>> "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would
>>> give a finer granularity.
>>
>> I think we should just add such tiling states to the window state enum,
>> rather than the draw state. The only point with putting things in the
>> draw state enum is to get the negotiation, while tiled vs not tiled is
>> closer to maximized vs not maximized, i.e. a compositor wouldn't change
>> its behaviour if the client couldn't not draw itself "tiled" or not.
> 
> Sorry, I did not make myself clear, I was not asking for tiling to a be a 
> draw state.
> 
>> As discussed in the bug you linked, there might be more to tiling than
>> shadow as well; it might effect rounded-ness of corners and maybe other
>> things as well, and adding "no_shadow_right" wouldn't address that.
> 
> No I was taking tiling as an example where we'd want the edge, so we might 
> consider having a "no shadow" value per edge as well, but not related to 
> tiling though.
> 
> This might come useful for surfaces placed next to the edge of a monitor in a 
> multi-monitor setup for example (so we don't have shadows crossing monitors 
> for example) - Maybe it's just overkill, dunno.
> 
> We could also consider "no border", again, per edge as well. Or not.
>

This last comments look to overlap with some already existing feature
within the protocol, I think about the input shape.

Also, because the issue is not well described the discussion overflow to
severals other issues.

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

Best regards
--
Benoit Gschwind

___
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

[Olivier Fourdan]

Hi Jonas,

- Original Message -
> On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
> > 
> > Do we really want reserved ranges here?
> > 
> > Some people reckon having (undocumented) reserved ranges was a bad idea in
> > "states", I wonder if we should redo this here again.
> > 
> > Undocumented states from the reserved range are unlikely to be adopted by
> > other desktops, and that might lead to duplication of similar mechanisms
> > with different values.
> 
> The purpose of a private range is not to have its values adopted by
> other desktop environments, but rather a place to put experimental
> things or things that might not suite a proper documented state. The
> ranges is intended so that different DE:s don't conflict.
> 
> I don't see what is wrong with that.

I see nothing wrong with it in a separate (optional) protocol for 
experimenting, but as soon as we have clients and compositors using private 
values out in the field, it might become harder to put things back into the 
agreed standard set. 

> The alternative is to have a separate configure event in an extension.
> It would work the same way, is a bit more code to write, but it'd
> effectively result in the same problem.
> > 
> > > +  
> > > +
> > > +  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.
> > > +
> > > +  
> > > +
> > 
> > Is a single "no shadow" state enough, isn't that too restrictive? If we put
> > this in perspective with a "tiled" state where we consider having
> > tiled_left/right/top/bottom, similarly, we could have "no_shadow_left",
> > "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would
> > give a finer granularity.
> 
> I think we should just add such tiling states to the window state enum,
> rather than the draw state. The only point with putting things in the
> draw state enum is to get the negotiation, while tiled vs not tiled is
> closer to maximized vs not maximized, i.e. a compositor wouldn't change
> its behaviour if the client couldn't not draw itself "tiled" or not.

Sorry, I did not make myself clear, I was not asking for tiling to a be a draw 
state.

> As discussed in the bug you linked, there might be more to tiling than
> shadow as well; it might effect rounded-ness of corners and maybe other
> things as well, and adding "no_shadow_right" wouldn't address that.

No I was taking tiling as an example where we'd want the edge, so we might 
consider having a "no shadow" value per edge as well, but not related to tiling 
though.

This might come useful for surfaces placed next to the edge of a monitor in a 
multi-monitor setup for example (so we don't have shadows crossing monitors for 
example) - Maybe it's just overkill, dunno.

We could also consider "no border", again, per edge as well. Or not.

Cheers,
Olivier


___
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

[Jonas Ådahl]

On Mon, May 30, 2016 at 05:01:58AM -0400, Olivier Fourdan wrote:
> Hi Mike,
> 
> Thanks for posting this, perfect timing to discuss this in light of the 
> tiling discussions ^_~
> 
> I reckon tiling and shadows can be related (even though one is an actual 
> state, the other is a draw state).
> 
> For a bit of background on my comments below, see 
> https://bugzilla.gnome.org/show_bug.cgi?id=766860
> 
> > this adds a method for compositors to change various draw attributes
> > for a surface
> > 
> > Signed-off-by: Mike Blumenkrantz 
> > Signed-off-by: Jonas Ådahl 
> > ---
> >  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
> > +  
> 
> Do we really want reserved ranges here?
> 
> Some people reckon having (undocumented) reserved ranges was a bad idea in 
> "states", I wonder if we should redo this here again.
> 
> Undocumented states from the reserved range are unlikely to be adopted by 
> other desktops, and that might lead to duplication of similar mechanisms with 
> different values.

The purpose of a private range is not to have its values adopted by
other desktop environments, but rather a place to put experimental
things or things that might not suite a proper documented state. The
ranges is intended so that different DE:s don't conflict.

I don't see what is wrong with that.

The alternative is to have a separate configure event in an extension.
It would work the same way, is a bit more code to write, but it'd
effectively result in the same problem.

> 
> > +  
> > +
> > +  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.
> > +
> > +  
> > +
> 
> Is a single "no shadow" state enough, isn't that too restrictive? If we put 
> this in perspective with a "tiled" state where we consider having 
> tiled_left/right/top/bottom, similarly, we could have "no_shadow_left", 
> "no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would give a 
> finer granularity.

I think we should just add such tiling states to the window state enum,
rather than the draw state. The only point with putting things in the
draw state enum is to get the negotiation, while tiled vs not tiled is
closer to maximized vs not maximized, i.e. a compositor wouldn't change
its behaviour if the client couldn't not draw itself "tiled" or not.

As discussed in the bug you linked, there might be more to tiling than
shadow as well; it might effect rounded-ness of corners and maybe other
things as well, and adding "no_shadow_right" wouldn't address that.


Jonas

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

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

[Olivier Fourdan]

Hi Mike,

Thanks for posting this, perfect timing to discuss this in light of the tiling 
discussions ^_~

I reckon tiling and shadows can be related (even though one is an actual state, 
the other is a draw state).

For a bit of background on my comments below, see 
https://bugzilla.gnome.org/show_bug.cgi?id=766860

> this adds a method for compositors to change various draw attributes
> for a surface
> 
> Signed-off-by: Mike Blumenkrantz 
> Signed-off-by: Jonas Ådahl 
> ---
>  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
> +  

Do we really want reserved ranges here?

Some people reckon having (undocumented) reserved ranges was a bad idea in 
"states", I wonder if we should redo this here again.

Undocumented states from the reserved range are unlikely to be adopted by other 
desktops, and that might lead to duplication of similar mechanisms with 
different values.

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

Is a single "no shadow" state enough, isn't that too restrictive? If we put 
this in perspective with a "tiled" state where we consider having 
tiled_left/right/top/bottom, similarly, we could have "no_shadow_left", 
"no_shadow_right", "no_shadow_top" and ""no_shadow_bottom", that would give a 
finer granularity.

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

Cheers,
Olivier
___
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

[Pekka Paalanen]

On Sat, 28 May 2016 08:39:59 -0500
Yong Bakos  wrote:

> Hi Mike,
> Regarding the combination of type="array" enum="foo"...
> 
> > On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
> >  wrote:
> > 
> > I've inlined some replies below.
> > 
> > On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > > wrote:
> > On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  > > wrote:  
> > >
> > > this adds a method for compositors to change various draw attributes
> > > for a surface
> > >
> > > Signed-off-by: Mike Blumenkrantz  > > >
> > > Signed-off-by: Jonas Ådahl >  
> > 
> > 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

> > > +
> > > +Calling this after an xdg_toplevel's first commit will raise a 
> > > client error.
> > > +  
> > > +
> > 
> > Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
> > scanner handle
> > this combination of array and enum correctly?
> > 
> > Good catch. This also affects the event above it.  
> 
> As we discussed via IRC (27 May), the scanner will choke on this. While we 
> talked about
> making a change to the scanner to allow this, perhaps such a change doesn't 
> make sense.
> 
> Given a type="array", scanner will generate a parameter of type wl_array.
> 
> Perhaps the short story here is to just remove the enum from this arg, and 
> the similar
> arg in the configure_draw_states event above. What do you think?
> 
> (I wonder if it's the DTD that can change, so the scanner's validation step
> will catch the unsupported combination of type="array" enum="foo". My gut 
> tells me that
> DTDs don't support this logic, but I'll dig into this.)

Hi,

here is some background.

A type="array" argument is really just a binary blob of data. The XML
description, human documentation aside, does not specify anything about
the blob contents. Therefore adding an XML attribute pointing to an
enum definition is half-useless. Generators could use it for creating
automatic links in documentation, but it cannot be used for code
generation, because you don't know the types contained in the blob.

We also do not want to add blob content type definitions to the XML
language, because you might want to have everything C is able to
express, including nested structs. There is also no requirement that
the "array" is really an array - every "element" could be a different
thing. It could be bitstream and whatnot. Only the use of
wl_array_for_each() implies it is an array of similar elements,
wl_array_add() does not.

The big point in adding enum annotations was that language bindings
generators (other than wayland-scanner) could use the annotation for
code generation. I don't think it is possible with the array type.

If we allow enum annotation with the array type, it will only be usable
for doc links, unlike the other enum annotations.

OTOH, we have lots and lots of places in the documentation texts that
refer to some request, event, interface, etc. that would be useful as a
hyperlink in the generated docs. Enums could fall into that as well, so
we would not need the attribute for only documentation.

Auke, Nils, what's your take on this matter?

We do have some documentation about enums in
https://wayland.freedesktop.org/docs/html/ch04.html#sect-Protocol-Basic-Principles



Thanks,
pq


pgpFaC_69tcw4.pgp
Description: OpenPGP digital signature
___
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

[Yong Bakos]

On May 28, 2016, at 9:51 AM, Mike Blumenkrantz  
wrote:
> 
> On Sat, May 28, 2016 at 9:40 AM Yong Bakos  > wrote:
> Hi Mike,
> Regarding the combination of type="array" enum="foo"...
> 
>> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>> > 
>> wrote:
>> 
>> I've inlined some replies below.
>> 
>> On Fri, May 27, 2016 at 1:13 PM Yong Bakos > > wrote:
>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz > > wrote:
>> >
>> > this adds a method for compositors to change various draw attributes
>> > for a surface
>> >
>> > Signed-off-by: Mike Blumenkrantz > > >
>> > Signed-off-by: Jonas Ådahl >
>> 
>> 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. 

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

[Mike Blumenkrantz]

On Sat, May 28, 2016 at 9:40 AM Yong Bakos  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  wrote:
>
>> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
>> wrote:
>> >
>> > this adds a method for compositors to change various draw attributes
>> > for a surface
>> >
>> > Signed-off-by: Mike Blumenkrantz 
>> > Signed-off-by: Jonas Ådahl 
>>
>> 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 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
>> > +

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

[Yong Bakos]

Hi Mike,
Regarding the combination of type="array" enum="foo"...

> On May 27, 2016, at 12:30 PM, Mike Blumenkrantz 
>  wrote:
> 
> I've inlined some replies below.
> 
> On Fri, May 27, 2016 at 1:13 PM Yong Bakos  > wrote:
> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  > wrote:
> >
> > this adds a method for compositors to change various draw attributes
> > for a surface
> >
> > Signed-off-by: Mike Blumenkrantz  > >
> > Signed-off-by: Jonas Ådahl >
> 
> 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 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 

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  wrote:

> On May 27, 2016, at 10:29 AM, Mike Blumenkrantz 
> wrote:
> >
> > this adds a method for compositors to change various draw attributes
> > for a surface
> >
> > Signed-off-by: Mike Blumenkrantz 
> > Signed-off-by: Jonas Ådahl 
>
> 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 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
>
> nit: that were advertised
>

"which" is correct and intended in this case.


>
> > +xdg_toplevel.set_available_draw_states.
> > +  
> > +  
> > +
> > +
> > +
> > +  
>
> nit: advertise available draw states
> Seems clearer, as there's no separation between "available" and
> "optional," since
> all draw states are 

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

[Yong Bakos]

On May 27, 2016, at 10:29 AM, Mike Blumenkrantz  wrote:
> 
> this adds a method for compositors to change various draw attributes
> for a surface
> 
> Signed-off-by: Mike Blumenkrantz 
> Signed-off-by: Jonas Ådahl 

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

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

> +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)

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

nit: not draw a

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

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

nit: that were advertised

> +xdg_toplevel.set_available_draw_states.
> +  
> +  
> +
> +
> +
> +  

nit: advertise available draw states
Seems clearer, as there's no separation between "available" and "optional," 
since
all draw states are optional. (Not being consistent here makes the reader 
second-
guess, "are there available ones and optional ones?")

> +Inform the compositor of optional draw states which are available
> +for the xdg_toplevel.

nit: of available draw states for the xdg_toplevel.
(same as previous reason)

> +
> +Calling this after an xdg_toplevel's first commit will raise a 
> client error.
> +  
> +  

Just a sanity check, since I haven't seen it in a protocol spec yet. Does 
scanner handle
this combination of array and enum correctly?

> +
> +
> 
>   
>   This configure event asks the client to resize its toplevel surface or
> -- 
> 2.5.5

yong


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

[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 
Signed-off-by: Jonas Ådahl 
---
 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