date:20160530

[PATCH libinput] touchpad: short-circuit the edge scroll handling when it's not enabled

2016-05-30 Thread Peter Hutterer

No need to handle events properly in the edge scroll state machine when it's
not enabled. Just set any beginning touch to state AREA and move on. The rest
of the code guarantees neutral state when edge scrolling is enabled or
disabled.

This reduces the debug output produced by libinput-debug-events when edge
scrolling is disabled, preventing users from seemingly identifying
bugs where there are none.

Signed-off-by: Peter Hutterer 
---
 src/evdev-mt-touchpad-edge-scroll.c | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/src/evdev-mt-touchpad-edge-scroll.c 
b/src/evdev-mt-touchpad-edge-scroll.c
index fcc0512..8222bba 100644
--- a/src/evdev-mt-touchpad-edge-scroll.c
+++ b/src/evdev-mt-touchpad-edge-scroll.c
@@ -318,6 +318,15 @@ tp_edge_scroll_handle_state(struct tp_dispatch *tp, 
uint64_t time)
 {
struct tp_touch *t;
 
+   if (tp->scroll.method != LIBINPUT_CONFIG_SCROLL_EDGE) {
+   tp_for_each_touch(tp, t) {
+   if (t->state == TOUCH_BEGIN)
+   t->scroll.edge_state =
+   EDGE_SCROLL_TOUCH_STATE_AREA;
+   }
+   return;
+   }
+
tp_for_each_touch(tp, t) {
if (!t->dirty)
continue;
@@ -350,9 +359,6 @@ tp_edge_scroll_post_events(struct tp_dispatch *tp, uint64_t 
time)
const struct normalized_coords zero = { 0.0, 0.0 };
const struct discrete_coords zero_discrete = { 0.0, 0.0 };
 
-   if (tp->scroll.method != LIBINPUT_CONFIG_SCROLL_EDGE)
-   return 0;
-
tp_for_each_touch(tp, t) {
if (!t->dirty)
continue;
-- 
2.7.4

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

Re: [RFC wayland] Add wl_proxy destruction callbacks

2016-05-30 Thread Daniel Vetter

On Mon, May 30, 2016 at 01:10:42PM +0200, Miguel Angel Vico wrote:
> 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.

Just a quick comment: I guess a piglit testcase to demonstrate the failure
(or well, just any minimal test) would be awesome. That way folks can
quickly figure out what all goes wrong without this.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
___
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

2016-05-30 Thread 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

2016-05-30 Thread 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

2016-05-30 Thread 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

2016-05-30 Thread 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
> > +the xdg_surface.configure event. Whe

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

2016-05-30 Thread 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

2016-05-30 Thread 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

2016-05-30 Thread 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 mailto:jad...@gmail.com>>  
> > 
> > Hi Mike & Jonas,
> > A question about communicating default state, and some
> > minor nits you can certainly ignore, inline below.
> > 
> >   
> > > ---
> > > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 69 
> > > 
> > > 1 file changed, 69 insertions(+)
> > >
> > > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > index dfd7e84..0fa76d4 100644
> > > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml

> > > +
> > > +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: Protocol for window previews/thumbnails

2016-05-30 Thread Olivier Fourdan

Hi Benoit,

On 28 May 2016 at 12:45, Benoit Gschwind  wrote:
> You should keep an eye on libweston  :)

Yes indeed, I do have great hopes in libweston :)

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

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

2016-05-30 Thread Olivier Fourdan

Hi Jonas,

- Original Message -
>  - maximum sized popups - it does not support letting a popup fill the
>work area in a predictable way (for example a vertical menu with very
>many elements should not be higher than the height of the work area
>it is drawn on). We could maybe consider adding using -intmax/intmax
>on the x/width or y/height to declare that and add a width/height to
>xdg_popup.configure. I have not prototyped nor do I know whether this
>is the kind of API GTK+ wants, and anyhow, its not supported as
>of today.

Yes, I reckon gtk+ would need this, as of today it checks for the output 
width/height and adds an arrow to scroll up/down if the entire menu doesn't fit 
in the output.

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

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

2016-05-30 Thread Jonas Ådahl

On Sat, May 28, 2016 at 08:22:53AM -0500, Yong Bakos wrote:
> Hi Jonas and Mike,
> 
> On May 25, 2016, at 11:32 PM, Jonas Ådahl  wrote:
> > 
> > xdg_positioner is a method for declarative positioning of child surfaces
> > (currently only xdg_popup surfaces). A client creates a description of a
> > positioning logic using the xdg_positioner interface. The xdg_positioner
> > object is then used when creating a xdg_popup for describing how the
> > child surface should be positioned in relation to the parent surface.
> > 
> > Signed-off-by: Jonas Ådahl 
> > Signed-off-by: Mike Blumenkrantz 
> 
> Whenever I see declarative positioning schemes, my warning bell goes off
> because, from the perspective of a gui/app dev, resulting implementations
> of constraint systems, etc can sometimes be a hassle. I'm not saying that
> what's proposed here is bad, rather, I ask, "Was this based on an
> existing system?" (Forgive me if that question is obvious / naive).

It was roughly based on an API used by Enlightenment. Support for using
it has also been prototyped in GTK+, and so far it seems possible to
implement all the popups etc available there. William Hua from
Cannonical has done most of the GTK+ side of things, although with the
intention to use it for the Mir backend. Not that Mir uses a slightly
similar approach[0] i.e. aligning a menu against a rectangle on a parent
surface.

> 
> In other words, there's an opportunity to create a simple, flexible,
> and anticipatable positioning mechanism here at the protocol level, so
> it's important to Do It Really Well.

Indeed. We have so far done it with the intention to make it
declarative, i.e. you don't "program" your position, you describe the
intention, and the compositor "programs" it given state only known to
it. I'm not sure how well versed you are of the background to this
protocol, but its main purpose is to keep popups (menus etc) within the
working region (maybe monitor area, or smaller, or larger, depending on
the compositor). Initially, the idea was to add a "probe" mechanism
letting clients check what parts of a would-be popup rectangle would be
outside of the work area, but that method did not play out well when
there are trasnformations and other things going on. Thus, we started
moving towards going for a more declerative direction where you set up
rules while letting the compositor do the positioning.

Note that given how xdg_positioner is made (rules added to an isolated
object), it is easy to add new rules in the future.

There are also a couple of things that are yet to be solved:

 - position adapted to a moving parent - the protocol does not handle
   repositioning of the popup when the parent changes the position. This
   would need various subsurface-like synchonization behaviours added.
   I think we can add this in the future if we actually want to, and I
   think it can be made in a backward compatible way.

 - maximum sized popups - it does not support letting a popup fill the
   work area in a predictable way (for example a vertical menu with very
   many elements should not be higher than the height of the work area
   it is drawn on). We could maybe consider adding using -intmax/intmax
   on the x/width or y/height to declare that and add a width/height to
   xdg_popup.configure. I have not prototyped nor do I know whether this
   is the kind of API GTK+ wants, and anyhow, its not supported as
   of today.

> 
> Acked-by: Yong Bakos 

Thanks


Jonas


[0] 
https://unity.ubuntu.com/mir/group__mir__toolkit.html#ga1bd26c06914622303d36b10fc473afed

> 
> yong
> 
> 
> > ---
> > 
> > Changes since v2:
> >  - Grammar, typos and spelling fixes
> >  - Reordered enum values to be the same as already present similar enum
> >  - Added enum attribute to relevant requests
> > 
> > 
> > unstable/xdg-shell/xdg-shell-unstable-v6.xml | 252 
> > ++-
> > 1 file changed, 249 insertions(+), 3 deletions(-)
> > 
> > diff --git a/unstable/xdg-shell/xdg-shell-unstable-v6.xml 
> > b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > index 07cbbc9..1baafa7 100644
> > --- a/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > +++ b/unstable/xdg-shell/xdg-shell-unstable-v6.xml
> > @@ -45,6 +45,8 @@
> >  summary="the client specified an invalid popup parent surface"/>
> >>  summary="the client provided an invalid surface state"/>
> > +   > +summary="the client provided an invalid positioner"/>
> > 
> > 
> > 
> > @@ -57,6 +59,15 @@
> >   
> > 
> > 
> > +
> > +  
> > +   Create a positioner object. A positioner object is used to position
> > +   surfaces relative to some parent surface. See the interface description
> > +   and xdg_surface.get_popup for details.
> > +  
> > +  
> > +
> > +
> > 
> >   
> > This creates an xdg_surface for the given surface. While xdg_surface
> > @@ -96,6 +107,225 @@
> > 
> >   
> > 
> > +  
> > +
> > +  The xdg_positioner provides

[PATCH libinput] touchpad: short-circuit the edge scroll handling when it's not enabled

Re: [RFC wayland] Add wl_proxy destruction callbacks

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

Re: [PATCH 1/5] scanner: Fixed doxygen group name for _add_listener

[RFC wayland] Add wl_proxy destruction callbacks

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

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

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

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

Re: Protocol for window previews/thumbnails

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

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

12 matches

Site Navigation

Mail list logo

Footer information