[RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user

Fri Oct 18 07:42:24 UTC 2019

On Fri, 18 Oct 2019 00:56:38 +0200
Carlos Garnacho <carlosg at gnome.org> wrote:

> Hi Dorota!
> 
> On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz <
> dorota.czaplejewicz at puri.sm> wrote:  
> 
> > On Wed, 16 Oct 2019 10:43:00 +0200
> > Carlos Garnacho <carlosg at gnome.org> wrote:
> >  
> > > This protocol takes over 3 different, but interrelated aspects of
> > > DE/client interaction:
> > > - Startup notification: presenting feedback about applications
> > >   being launched, either through the compositor or another client
> > > - Focus stealing prevention: letting the compositor figure out
> > >   whether immediately switching focus to a surface makes sense.
> > > - Window raising/activation: allowing existing clients to request
> > >   focus in a controlled manner.
> > >
> > > Signed-off-by: Carlos Garnacho <carlosg at gnome.org>
> > > ---
> > >  Makefile.am                                   |   1 +
> > >  unstable/presentation/README                  |   5 +
> > >  .../presentation/presentation-unstable-v1.xml | 175 ++++++++++++++++++
> > >  3 files changed, 181 insertions(+)
> > >  create mode 100644 unstable/presentation/README
> > >  create mode 100644 unstable/presentation/presentation-unstable-v1.xml
> > >
> > > diff --git a/Makefile.am b/Makefile.am
> > > index d2c89a8..bd0e52d 100644
> > > --- a/Makefile.am
> > > +++ b/Makefile.am
> > > @@ -24,6 +24,7 @@ unstable_protocols =  
> >                               \  
> > >       unstable/xdg-decoration/xdg-decoration-unstable-v1.xml  \
> > >  
> >  unstable/linux-explicit-synchronization/linux-explicit-synchronization-unstable-v1.xml
> > \  
> > >       unstable/primary-selection/primary-selection-unstable-v1.xml  
> >       \  
> > > +     unstable/presentation/presentation-unstable-v1.xml  
> >       \  
> > >       $(NULL)
> > >
> > >  stable_protocols =  
> >      \  
> > > diff --git a/unstable/presentation/README b/unstable/presentation/README
> > > new file mode 100644
> > > index 0000000..5a77e97
> > > --- /dev/null
> > > +++ b/unstable/presentation/README
> > > @@ -0,0 +1,5 @@
> > > +Presentation protocol
> > > +
> > > +Maintainers:
> > > +Carlos Garnacho <carlosg at gnome.org>
> > > +
> > > diff --git a/unstable/presentation/presentation-unstable-v1.xml  
> > b/unstable/presentation/presentation-unstable-v1.xml  
> > > new file mode 100644
> > > index 0000000..84bf961
> > > --- /dev/null
> > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > @@ -0,0 +1,175 @@
> > > +<?xml version="1.0" encoding="UTF-8"?>
> > > +<protocol name="presentation_v1">
> > > +  <copyright>
> > > +    Copyright 2018-2019 © Red Hat, Inc.
> > > +
> > > +    Permission is hereby granted, free of charge, to any person
> > > +    obtaining a copy of this software and associated documentation files
> > > +    (the "Software"), to deal in the Software without restriction,
> > > +    including without limitation the rights to use, copy, modify, merge,
> > > +    publish, distribute, sublicense, and/or sell copies of the Software,
> > > +    and to permit persons to whom the Software is furnished to do so,
> > > +    subject to the following conditions:
> > > +
> > > +    The above copyright notice and this permission notice (including the
> > > +    next paragraph) shall be included in all copies or substantial
> > > +    portions of the Software.
> > > +
> > > +    THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND,
> > > +    EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF
> > > +    MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
> > > +    NONINFRINGEMENT.  IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
> > > +    BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN
> > > +    ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
> > > +    CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
> > > +    SOFTWARE.
> > > +  </copyright>
> > > +
> > > +  <description summary="Presentation request protocol">
> > > +    This description provides a high-level overview of the interplay  
> > between  
> > > +    the interfaces defined this protocol. For details, see the protocol
> > > +    specification.
> > > +
> > > +    The finality of the protocol is defining a compositor context for
> > > +    surfaces requesting to be presented. Presentation requests are  
> > usually  
> > > +    initiated by an existing surface, and acknowledged by a surface  
> > being  
> > > +    mapped. By having both ends talk with the compositor through this  
> > protocol,  
> > > +    the compositor has the information to implement different  
> > commonplace  
> > > +    policies:  
> >
> > Why does a presentation request have to come from a surface? I would
> > expect that, similarly to creating a surface, presenting it would not
> > require anything but a client (and maybe even no specific client) at least
> > in the case of startup notification.
> >  
> 
> Wrt the startup notification aspect of this protocol, the reasoning was
> that the spawning of UI-less processes (wayland clients or not) is rarely
> worth UI feedback. I think my reasoning makes sense, but perhaps there's
> some usecase I missed?
> 
> However, the other aspects (activation, focus stealing prevention) do
> require a surface, so if the consensus is that we shouldn't do that for
> startup notification, should probably be split somehow.

Hi,

I wonder if the question was about...

> > > +  <interface name="zwp_presentation_manager" version="1">
> > > +    <request name="create_presenter" since="1">
> > > +      <description summary="create a new presenter">
> > > +     Creates a new presenter.
> > > +
> > > +     The surface argument is the toplevel that initiated the  
> > presentation  
> > > +     request through user input. Compositors may want to place the  
> > presented  
> > > +     surface relative to the presenter.
> > > +
> > > +     Compositors that desire to implement focus stealing prevention
> > > +     may use this request to find out the request time.
> > > +      </description>
> > > +      <arg name="id" type="new_id" interface="zwp_presenter"/>
> > > +      <arg name="surface" type="object" interface="wl_surface"/>
> > > +      <arg name="serial" type="uint" summary="the serial from the input
> > event"/>

...this request?

Why is a wl_surface needed here? Is tying this to an input event via
the serial not enough?

It is hard to get any kind of input if the client does not have a
visible wl_surface to receive input on, but I don't immediately see why
the window needs to be mentioned here explicitly.

> > > +    </request>
> > > +
> > > +    <request name="acknowledge" since="1">
> > > +      <description summary="acknowledges a presentation token">
> > > +     Acknowledges that the calling client handled the presentation  
> > token.  
> > > +
> > > +     Applications will typically receive this through the  
> > DESKTOP_STARTUP_ID  
> > > +     environment variable as set by its launcher, and should unset the
> > > +     environment variable right after this request, in order to avoid
> > > +     propagating it to child processes.
> > > +
> > > +     Compositors will ignore unknown presentation tokens.
> > > +
> > > +     Presentation tokens may be transferred across clients through  
> > means not  
> > > +     described in this protocol.
> > > +      </description>
> > > +      <arg name="token" type="string"/>
> > > +      <arg name="surface" type="object" interface="wl_surface"/>

I can buy the argument for having a wl_surface here for launch
feedback, and for activation it is necessary.

OTOH, the surface argument could be nullable if it is not always
mandatory.

> > > +    </request>
> > > +

Thanks,
pq
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.freedesktop.org/archives/wayland-devel/attachments/20191018/bc3d1fb8/attachment.sig>