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 1/5] scanner: Fixed doxygen group name for _add_listener

[Bill Spitzak]

I did test this, it makes the add_listener functions show up in the doxygen
output.

I noticed this because I copied the incorrect line to add my own functions
and was wondering why they were not coming out in the doxygen output.
​
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel

[RFC wayland] Add wl_proxy destruction callbacks

[Miguel Angel Vico]

Hi all,

A few days ago, I had a little chat over IRC with Pekka about addition
of proxy objects destruction callbacks to the wayland client protocol.


Summing up, we recently ran into some applications where native objects
(wl_surface, wl_egl_window, wl_display) used by EGL are destroyed/made
invalid before destroying the corresponding EGL objects. This sometimes
causes crashes of the EGL driver, which is not nice. We have seen this
with the NVIDIA EGL implementation, but I assume the Mesa EGL
implementation is similarly exposed.

I agree this is in fact an application bug, but the EGL spec states that
functions such as makeCurrent or swapBuffers should return error (not
crash) if the native objects become invalid. I also agree the spec
should have been clearer and probably allowed "undefined behavior", but
it is not the case.

Having an objects destruction notification mechanism such as destruction
callbacks would allow us to satisfy the spec.

Also, such functionality would also make life way easier under certain
circumstances. I'm basically thinking about multi-threaded applications,
where several threads make use of the same native objects, and for some
reason one of the threads has to destroy one or more of them due to some
sort of error happening.

Of course, this can still be considered an application bug, and the
application could still make sure none of the threads is going to use
the native objects before destroying them, but again, specs allow users
to do many non-recommended things.

I think we should try to do our best to gracefully handle those
non-desirable API usages, and avoid crashes whenever is possible.


Pekka did not see this as something crazy to have, but wanted to hear
from some of the toolkits guys before making the decision of whether
changing the wl_proxy ABI is a good idea.


As an alternative, destruction callbacks could be hung off of
wl_egl_window. In a similar way we support wl_egl_window_resize
callbacks, we could support wl_egl_window_destroy callbacks.

However, this isn't as foolproof as adding wl_proxy destruction
callbacks, since destruction of wl_surface or wl_display objects before
wl_egl_window would lead to same issues.


I really think adding destruction callbacks to wl_proxy would be an
improvement worth making, but others' thoughts must be heard first.


Thanks,

-- 
Miguel


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

[PATCH wayland-protocols v7] text: Create second version of text input protocol

[Jan Arne Petersen]

There were some shortcomings in the first version of the protocol which
makes it not really useful in real world applications. It is not really
possible to fix them in a compatible way so introduce a new v2 of the
protocol.

Fixes some shortcomings of the first version:

* Use only one wp_text_input per wl_seat (client side should be
  handled by client toolkit)
* Allow focus tracking without wl_keyboard present
* Improve update state handling and better define state handling
---
Changes to v6:
* Fix some typos

 Makefile.am|   1 +
 unstable/text-input/text-input-unstable-v2.xml | 480 +
 2 files changed, 481 insertions(+)
 create mode 100644 unstable/text-input/text-input-unstable-v2.xml

diff --git a/Makefile.am b/Makefile.am
index 71d2632..cc8d531 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,7 @@ unstable_protocols =
\
unstable/fullscreen-shell/fullscreen-shell-unstable-v1.xml  
\
unstable/linux-dmabuf/linux-dmabuf-unstable-v1.xml  
\
unstable/text-input/text-input-unstable-v1.xml  
\
+   unstable/text-input/text-input-unstable-v2.xml  
\
unstable/input-method/input-method-unstable-v1.xml  
\
unstable/xdg-shell/xdg-shell-unstable-v5.xml
\
unstable/relative-pointer/relative-pointer-unstable-v1.xml  
\
diff --git a/unstable/text-input/text-input-unstable-v2.xml 
b/unstable/text-input/text-input-unstable-v2.xml
new file mode 100644
index 000..ea35d9b
--- /dev/null
+++ b/unstable/text-input/text-input-unstable-v2.xml
@@ -0,0 +1,480 @@
+
+
+
+  
+Copyright © 2012, 2013 Intel Corporation
+Copyright © 2015, 2016 Jan Arne Petersen
+
+Permission to use, copy, modify, distribute, and sell this
+software and its documentation for any purpose is hereby granted
+without fee, provided that the above copyright notice appear in
+all copies and that both that copyright notice and this permission
+notice appear in supporting documentation, and that the name of
+the copyright holders not be used in advertising or publicity
+pertaining to distribution of the software without specific,
+written prior permission.  The copyright holders make no
+representations about the suitability of this software for any
+purpose.  It is provided "as is" without express or implied
+warranty.
+
+THE COPYRIGHT HOLDERS DISCLAIM ALL WARRANTIES WITH REGARD TO THIS
+SOFTWARE, INCLUDING ALL IMPLIED WARRANTIES OF MERCHANTABILITY AND
+FITNESS, IN NO EVENT SHALL THE COPYRIGHT HOLDERS BE LIABLE FOR ANY
+SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES OR ANY DAMAGES
+WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS, WHETHER IN
+AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS ACTION,
+ARISING OUT OF OR IN CONNECTION WITH THE USE OR PERFORMANCE OF
+THIS SOFTWARE.
+  
+
+  
+
+  The zwp_text_input_v2 interface represents text input and input methods
+  associated with a seat. It provides enter/leave events to follow the
+  text input focus for a seat.
+
+  Requests are used to enable/disable the text-input object and set
+  state information like surrounding and selected text or the content type.
+  The information about the entered text is sent to the text-input object
+  via the pre-edit and commit events. Using this interface removes the need
+  for applications to directly process hardware key events and compose text
+  out of them.
+
+  Text is valid UTF-8 encoded, indices and lengths are in bytes. Indices
+  have to always point to the first byte of an UTF-8 encoded code point.
+  Lengths are not allowed to contain just a part of an UTF-8 encoded code
+  point.
+
+  State is sent by the state requests (set_surrounding_text,
+  set_content_type, set_cursor_rectangle and set_preferred_language) and
+  an update_state request. After an enter or an input_method_change event
+  all state information is invalidated and needs to be resent from the
+  client. A reset or entering a new widget on client side also
+  invalidates all current state information.
+
+
+
+  
+   Destroy the wp_text_input object. Also disables all surfaces enabled
+   through this wp_text_input object
+  
+
+
+
+  
+   Enable text input in a surface (usually when a text entry inside of it
+   has focus).
+
+   This can be called before or after a surface gets text (or keyboard)
+   focus via the enter event. Text input to a surface is only active
+   when it has the current text (or keyboard) focus and is enabled.
+  
+  
+
+
+
+  
+   Disable text input in a surface (typically when there is no focus on any
+   text 

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