[PATCH weston 1/6] xdg-shell: define the present/present_from_event() requests

Manuel Bachmann manuel.bachmann at iot.bzh
Fri Oct 2 06:32:47 PDT 2015


Hi Jonas, Daniel, Derek, Bill,

My apologizes for the late answer, I initiallty wanted to come back Monday
with a new test case, and missed some answers.

* Jonas, good point, I forgot to bump the protocol here. I really think it
fits into xdg-shell ; what are you thinking of when you are referring to an
extension ? An additional .xml ? If it can be done without breaking
anything, I would be happy to push it for review.

Regarding the core of the topic - and the usefulness of these requests - my
point is that  :
- it is useful to desktop software (messaging IRC clients, text editors,
browsers, etc..) ;
- embedded-oriented distributions, such as AGL, will definitely need it as
it is a common usecase for their Wayland backends.

 I wanted to showcase a heavy client such as Empathy implementing this, it
unfortunately got delayed, but I'll try to have it ASAP.

* Daniels, I totally agree with you that "raise()" is a bad choice of
wording, it offers false expectations, and we agreed with Jasper that
present() is a lot better (plus, it resembles a "present()" function
present in popular toolkits such as GTK+) ;

* Bill, Derek, about having a single request which always takes a serial
argument : I initially thought the same because it seems a lot cleaner,
but as no consensus was reached, and Wayland wants to position itself as a
stable protocol, I think we better have the double request model for now.

Thanks a lot for your time and patience.





Regards,

*Manuel Bachmann, Graphics Engineer www.iot.bzh <http://iot.bzh> *


2015-10-02 4:07 GMT+02:00 Jonas Ã…dahl <jadahl at gmail.com>:

> On Thu, Apr 09, 2015 at 06:22:53PM +0200, Manuel Bachmann wrote:
> > xdg_surface_present() and xdg_surface_present_from_event()
> > are new requests supposed to be called on an existing
> > xdg_surface. They tell the compositor that the surface
> > has new content which may be of interest to the user.
> > The compositor may then choose to notify the user.
> >
> > xdg_surface_present_from_event() takes a serial coming
> > from an input (wl_keyboard, wl_pointer, wl_touch) event as
> > an argument. If the serial is valid and sufficiently recent,
> > we can suppose the new content has been issued at the user's
> > request ; the compositor may then choose to raise the
> > surface directly. Otherwise, it just behaves like present().
> >
> > Signed-off-by: Manuel Bachmann <manuel.bachmann at open.eurogiciel.org>
> > ---
> >  desktop-shell/shell.c  | 15 +++++++++++++++
> >  protocol/xdg-shell.xml | 20 ++++++++++++++++++++
> >  2 files changed, 35 insertions(+)
> >
> > diff --git a/desktop-shell/shell.c b/desktop-shell/shell.c
> > index f7c928e..d1d3f3c 100644
> > --- a/desktop-shell/shell.c
> > +++ b/desktop-shell/shell.c
> > @@ -3923,6 +3923,19 @@ xdg_surface_set_minimized(struct wl_client
> *client,
> >       set_minimized(shsurf->surface);
> >  }
> >
> > +static void
> > +xdg_surface_present(struct wl_client *client,
> > +                 struct wl_resource *resource)
> > +{
> > +}
> > +
> > +static void
> > +xdg_surface_present_from_event(struct wl_client *client,
> > +                            struct wl_resource *resource,
> > +                            uint32_t serial)
> > +{
> > +}
> > +
> >  static const struct xdg_surface_interface xdg_surface_implementation = {
> >       xdg_surface_destroy,
> >       xdg_surface_set_parent,
> > @@ -3938,6 +3951,8 @@ static const struct xdg_surface_interface
> xdg_surface_implementation = {
> >       xdg_surface_set_fullscreen,
> >       xdg_surface_unset_fullscreen,
> >       xdg_surface_set_minimized,
> > +     xdg_surface_present,
> > +     xdg_surface_present_from_event,
> >  };
> >
> >  static void
> > diff --git a/protocol/xdg-shell.xml b/protocol/xdg-shell.xml
> > index 68cf469..10f82c5 100644
> > --- a/protocol/xdg-shell.xml
> > +++ b/protocol/xdg-shell.xml
> > @@ -396,6 +396,26 @@
> >        </description>
> >      </request>
> >
> > +    <request name="present">
> > +      <description summary="the window wants attention from the user">
> > +     The surface has new content and would like the compositor
> > +     to notify the user.
> > +      </description>
> > +    </request>
> > +
> > +    <request name="present_from_event">
> > +      <description summary="the window needs attention from the user">
> > +     The surface has new content and would like the compositor
> > +     to notify the user.
> > +
> > +     If a valid and sufficiently recent serial coming from an
> > +     input (keyboard, pointer, touch) event is passed as an
> > +     argument, the compositor may want to raise the surface.
> > +     Otherwise, the request just behaves like the "present" one.
> > +      </description>
> > +      <arg name="serial" type="uint" summary="serial of an input
> event"/>
> > +    </request>
> > +
>
> This changes the protocol without bumping any versions. I'm also a bit
> skeptical to, at this point, doing non-essential changes to xdg_shell.
> Changing the experimental version is a huge pain because a version
> mismatch causes any mismatching client trying to use it to be
> terminated, without any way to discover whether it is compatible or not.
> Could we maybe add this as an extension to xdg_shell or something like
> that?
>
>
> Jonas
>
> >      <event name="close">
> >        <description summary="surface wants to be closed">
> >          The close event is sent by the compositor when the user
> > --
> > 1.8.3.1
> >
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151002/a43ba379/attachment.html>


More information about the wayland-devel mailing list