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

2019-12-17 Thread David Edmundson
Thanks for working on this, activation is something key that we are
sorely missing.

If we want a complete 1:1 port of the X11 protocol, this certainly
technically fine, other than my one minor comment.

I dislike the X11 spec, so it's not my preference moving forward.
The main thing I dislike is that it requires the surface releasing
focus to know what it will be launching.

Especially with flatpal + xdg portal we're increasingly going to be to
want to pass focus without knowing to whom.
Similarly, dbus activation on a common name such as filemanager1 could
be to any app.

The other thing I've had a problem with is that historically we have a
lot of problems with apps not clearing their startup notifications.
This was especially true of apps that immediately dock to the status
icon, something this spec would have a problem with, unless we allow
nulls to the acknowledge request.

IMHO we can get something cleaner if we treat it as two independent problems.
* Passing focus
* Startup notifications

One is conceptually passing data from surface-> surface
The other is passing data app -> the shell

There's some overlap, but not a lot.

Personally I would also like to see set_activation_token(string, seat,
serial) and activate(string) be methods on xdg_toplevel, partly
because they're so integral to everyday operation, partly because it's
the only surface type we want to activate.


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


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

2019-12-17 Thread David Edmundson
> +  
> +  
> +  
> +
> +

Passing a serial also needs a wl_seat object to relate the two
___
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/wayland-devel


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

2019-11-13 Thread Guido Günther
Hi Carlos,
On Fri, Oct 18, 2019 at 01:08:36AM +0200, Carlos Garnacho wrote:
> Hi Pekka,
> 
> Thank you for your comments!
> 
> On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen  wrote:
> 
> > On Wed, 16 Oct 2019 10:54:08 +0200
> > Olivier Fourdan  wrote:
> >
> > > Hey Carlos,
> > >
> > > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho 
> > 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 
> >
> > Hi Carlos,
> >
> > this seems well written and a good idea to me. More comments inline.
> >
> > > > ---
> > > >  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 000..5a77e97
> > > > --- /dev/null
> > > > +++ b/unstable/presentation/README
> > > > @@ -0,0 +1,5 @@
> > > > +Presentation protocol
> > > > +
> > > > +Maintainers:
> > > > +Carlos Garnacho 
> > > > +
> > > > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> > b/unstable/presentation/presentation-unstable-v1.xml
> > > > new file mode 100644
> > > > index 000..84bf961
> > > > --- /dev/null
> > > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > > @@ -0,0 +1,175 @@
> > > > +
> > > > +
> > > > +  
> > > > +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.
> > > > +  
> > > > +
> > > > +  
> > > > +This description provides a high-level overview of the interplay
> > between
> > > > +the interfaces defined this protocol. For details, see the
> > protocol
> > > > +specification.
> >
> > This is the protocol specification, the whole file.
> >
> 
> Uh, got that bit of the wording from zwp_tablet, removed locally :).
> 
> 
> >
> > > > +
> > > > +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:
> > > > +
> > > > +- 

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

2019-10-18 Thread Pekka Paalanen
On Fri, 18 Oct 2019 01:08:36 +0200
Carlos Garnacho  wrote:

> Hi Pekka,
> 
> Thank you for your comments!

Hi Carlos,

I pretty much agreed with all your responses, just few things to
elaborate further below.

> 
> On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen  wrote:
> 
> > On Wed, 16 Oct 2019 10:54:08 +0200
> > Olivier Fourdan  wrote:
> >  
> > > Hey Carlos,
> > >
> > > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho   
> > 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   
> >
> > Hi Carlos,
> >
> > this seems well written and a good idea to me. More comments inline.
> >  
> > > > ---
> > > >  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

...

> > > > +  
> > > > +
> > > > +  
> > > > +   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.  
> >
> > The serial argument should be explained here. It might be hard,
> > because we have been really poor at explaining the serials.
> >  
> 
> Will try :).
> 
> 
> >
> > Do we not also need to specify the wl_seat for which the input serial
> > is associated to?
> >  
> 
> Hm, right.
> 
> 
> >  
> > > > +  
> > > > +  
> > > > +
> >
> > If you use wl_surface as the type here, what about when the role is not
> > a toplevel? Should that result in a protocol error?
> >  
> 
> That sounds like a good idea.
> 
> 
> >
> > What defines a "toplevel"?
> >  
> 
> My guess is that xdg_toplevel / wl_shell_surface are the targets.

Right. We might want a sentence deferring the definition of "toplevel"
to other extensions and mention xdg_toplevel as an example - unless the
interface starts using xdg_toplevel specifically.

I would not care to add support for wl_shell stuff in new extensions.


> >  
> > > > +
> > > > +
> > > > +

...

> > > > +  
> > > > +
> > > > +  The wp_presenter object allows clients to get the necessary  
> > context to  
> > > > +  request that another surface or client should be presented to  
> > the user.  
> > > > +
> > > > +
> > > > +
> > > > +
> > > > +   Sets the app ID of the application to be launched, the  
> > compositor  
> > > > +   may use this information to look up other miscellaneous  
> > information  
> > > > +   about it (eg. translatable name, icon, …).
> > > > +
> > > > +   Clients do not need to set an app ID for presentation requests
> > > > +   meant to map surfaces owned by the same client.  
> >
> > "Do not need" or "must not"?
> >  
> 
> It's perhaps a good idea to stick to the latter.

Btw. if this mechanism is intended for cross-application activation
only, then the text about own surfaces would need to be dropped. I'm
referring to your PDF opening example.


> >
> > Is it possible to send an app ID that is obviously invalid and should
> > result in a protocol error?
> >  
> 
> That wording has been taken straight from xdg-shell, both should probably
> be kept in sync. Same restrictions apply, too :).

Ok. I was just wondering if it needs a protocol error defined.
Following xdg-shell is good I suppose.


> > > > +
> > > > +
> > > > +
> > > > +  
> > > > +   Destroys this zwp_presenter object.
> > > > +  
> > > > +
> > > > +
> > > > +
> > > > +  
> > > > +   Notifies of an unique presentation token (eg. UUIDs) to be  
> > used for the  
> > > > +   application about to be launched.  
> >
> > When is this event sent?
> >  
> 
> Right after the presenter is created. I've got a bit of a sore point here,
> since obtaining presenter+token requires a roundtrip on the client.

The roundtrip is necessary, since the compositor is creating the token
to ensure it is unique enough.

The spec should say when this event is sent, I didn't find that.


> > > > +
> > > > +   In order to guarantee 

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

2019-10-18 Thread Pekka Paalanen
On Fri, 18 Oct 2019 00:56:38 +0200
Carlos Garnacho  wrote:

> Hi Dorota!
> 
> On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz <
> dorota.czaplejew...@puri.sm> wrote:  
> 
> > On Wed, 16 Oct 2019 10:43:00 +0200
> > Carlos Garnacho  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 
> > > ---
> > >  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 000..5a77e97
> > > --- /dev/null
> > > +++ b/unstable/presentation/README
> > > @@ -0,0 +1,5 @@
> > > +Presentation protocol
> > > +
> > > +Maintainers:
> > > +Carlos Garnacho 
> > > +
> > > diff --git a/unstable/presentation/presentation-unstable-v1.xml  
> > b/unstable/presentation/presentation-unstable-v1.xml  
> > > new file mode 100644
> > > index 000..84bf961
> > > --- /dev/null
> > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > @@ -0,0 +1,175 @@
> > > +
> > > +
> > > +  
> > > +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.
> > > +  
> > > +
> > > +  
> > > +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 

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

2019-10-17 Thread Carlos Garnacho
Hi Pekka,

Thank you for your comments!

On Wed, Oct 16, 2019 at 11:31 AM Pekka Paalanen  wrote:

> On Wed, 16 Oct 2019 10:54:08 +0200
> Olivier Fourdan  wrote:
>
> > Hey Carlos,
> >
> > On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho 
> 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 
>
> Hi Carlos,
>
> this seems well written and a good idea to me. More comments inline.
>
> > > ---
> > >  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 000..5a77e97
> > > --- /dev/null
> > > +++ b/unstable/presentation/README
> > > @@ -0,0 +1,5 @@
> > > +Presentation protocol
> > > +
> > > +Maintainers:
> > > +Carlos Garnacho 
> > > +
> > > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> b/unstable/presentation/presentation-unstable-v1.xml
> > > new file mode 100644
> > > index 000..84bf961
> > > --- /dev/null
> > > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > > @@ -0,0 +1,175 @@
> > > +
> > > +
> > > +  
> > > +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.
> > > +  
> > > +
> > > +  
> > > +This description provides a high-level overview of the interplay
> between
> > > +the interfaces defined this protocol. For details, see the
> protocol
> > > +specification.
>
> This is the protocol specification, the whole file.
>

Uh, got that bit of the wording from zwp_tablet, removed locally :).


>
> > > +
> > > +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:
> > > +
> > > +- Startup notification: The compositor may track wp_presenter
> interfaces
> > > +  being created from the launcher side, and replied upon on the
> launchee
> > > +  side. Compositors may also perform the application launcher role
> > > +  themselves.
>
> Ok, I see that.
>
> > > +
> > > +- Focus stealing prevention: The 

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

2019-10-17 Thread Carlos Garnacho
Hi Dorota!

On Wed, Oct 16, 2019 at 11:16 AM Dorota Czaplejewicz <
dorota.czaplejew...@puri.sm> wrote:

> On Wed, 16 Oct 2019 10:43:00 +0200
> Carlos Garnacho  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 
> > ---
> >  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 000..5a77e97
> > --- /dev/null
> > +++ b/unstable/presentation/README
> > @@ -0,0 +1,5 @@
> > +Presentation protocol
> > +
> > +Maintainers:
> > +Carlos Garnacho 
> > +
> > diff --git a/unstable/presentation/presentation-unstable-v1.xml
> b/unstable/presentation/presentation-unstable-v1.xml
> > new file mode 100644
> > index 000..84bf961
> > --- /dev/null
> > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > @@ -0,0 +1,175 @@
> > +
> > +
> > +  
> > +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.
> > +  
> > +
> > +  
> > +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.


>
> > +
> > +- Startup notification: The compositor may track wp_presenter
> interfaces
> > +  being created from the launcher side, and replied upon on 

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

2019-10-17 Thread Carlos Garnacho
Hey :),

On Wed, Oct 16, 2019 at 10:54 AM Olivier Fourdan 
wrote:

> The name itself, “presentation” might be confusing considering we
> already have a “presentation-time” protocol.
>

Right... I'm open to naming suggestions. Struggled a bit there, other
single word that I could come up with are "activation" or "launch",
"presentation" sounded more neutral though.

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

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

2019-10-16 Thread Pekka Paalanen
On Wed, 16 Oct 2019 10:54:08 +0200
Olivier Fourdan  wrote:

> Hey Carlos,
> 
> On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho  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 

Hi Carlos,

this seems well written and a good idea to me. More comments inline.

> > ---
> >  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 000..5a77e97
> > --- /dev/null
> > +++ b/unstable/presentation/README
> > @@ -0,0 +1,5 @@
> > +Presentation protocol
> > +
> > +Maintainers:
> > +Carlos Garnacho 
> > +
> > diff --git a/unstable/presentation/presentation-unstable-v1.xml 
> > b/unstable/presentation/presentation-unstable-v1.xml
> > new file mode 100644
> > index 000..84bf961
> > --- /dev/null
> > +++ b/unstable/presentation/presentation-unstable-v1.xml
> > @@ -0,0 +1,175 @@
> > +
> > +
> > +  
> > +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.
> > +  
> > +
> > +  
> > +This description provides a high-level overview of the interplay 
> > between
> > +the interfaces defined this protocol. For details, see the protocol
> > +specification.

This is the protocol specification, the whole file.

> > +
> > +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:
> > +
> > +- Startup notification: The compositor may track wp_presenter 
> > interfaces
> > +  being created from the launcher side, and replied upon on the 
> > launchee
> > +  side. Compositors may also perform the application launcher role
> > +  themselves.

Ok, I see that.

> > +
> > +- Focus stealing prevention: The compositor may know whether there is
> > +  recent user input that happened after the presentation request, and
> > +  ensure no disruptions happen.

This might need elaboration on how this is supposed to work.

> > +
> > +- Window raising/activation: The presented 

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

2019-10-16 Thread Dorota Czaplejewicz
On Wed, 16 Oct 2019 10:43:00 +0200
Carlos Garnacho  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 
> ---
>  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 000..5a77e97
> --- /dev/null
> +++ b/unstable/presentation/README
> @@ -0,0 +1,5 @@
> +Presentation protocol
> +
> +Maintainers:
> +Carlos Garnacho 
> +
> diff --git a/unstable/presentation/presentation-unstable-v1.xml 
> b/unstable/presentation/presentation-unstable-v1.xml
> new file mode 100644
> index 000..84bf961
> --- /dev/null
> +++ b/unstable/presentation/presentation-unstable-v1.xml
> @@ -0,0 +1,175 @@
> +
> +
> +  
> +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.
> +  
> +
> +  
> +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.

> +
> +- Startup notification: The compositor may track wp_presenter interfaces
> +  being created from the launcher side, and replied upon on the launchee
> +  side. Compositors may also perform the application launcher role
> +  themselves.
> +
> +- Focus stealing prevention: The compositor may know whether there is
> +  recent user input that happened after the presentation request, and
> +  ensure no disruptions happen.
> +
> +- Window raising/activation: The presented surface may be another 
> previously
> +  existing one, which might require bringing it to focus.

"may be another" - is there a word like "related to" missing?

> +
> +A client that wishes to present another surface (of its own or from 
> another
> +client) 

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

2019-10-16 Thread Olivier Fourdan
Hey Carlos,

On Wed, Oct 16, 2019 at 10:43 AM Carlos Garnacho  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 
> ---
>  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 000..5a77e97
> --- /dev/null
> +++ b/unstable/presentation/README
> @@ -0,0 +1,5 @@
> +Presentation protocol
> +
> +Maintainers:
> +Carlos Garnacho 
> +
> diff --git a/unstable/presentation/presentation-unstable-v1.xml 
> b/unstable/presentation/presentation-unstable-v1.xml
> new file mode 100644
> index 000..84bf961
> --- /dev/null
> +++ b/unstable/presentation/presentation-unstable-v1.xml
> @@ -0,0 +1,175 @@
> +
> +
> +  
> +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.
> +  
> +
> +  
> +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:
> +
> +- Startup notification: The compositor may track wp_presenter interfaces
> +  being created from the launcher side, and replied upon on the launchee
> +  side. Compositors may also perform the application launcher role
> +  themselves.
> +
> +- Focus stealing prevention: The compositor may know whether there is
> +  recent user input that happened after the presentation request, and
> +  ensure no disruptions happen.
> +
> +- Window raising/activation: The presented surface may be another 
> previously
> +  existing one, which might require bringing it to focus.
> +
> +A client that wishes to present another surface (of its own or from 
> another
> +client) will call wp_presentation_manager.create_presenter to create a
> +presentation request. Compositors may use this object to track the 
> source of
> +the request in order to apply its policies when mapping the surface or
> +bringing an existing one to focus.
> +
> +In the presented surface 

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

2019-10-16 Thread Carlos Garnacho
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 
---
 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 000..5a77e97
--- /dev/null
+++ b/unstable/presentation/README
@@ -0,0 +1,5 @@
+Presentation protocol
+
+Maintainers:
+Carlos Garnacho 
+
diff --git a/unstable/presentation/presentation-unstable-v1.xml 
b/unstable/presentation/presentation-unstable-v1.xml
new file mode 100644
index 000..84bf961
--- /dev/null
+++ b/unstable/presentation/presentation-unstable-v1.xml
@@ -0,0 +1,175 @@
+
+
+  
+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.
+  
+
+  
+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:
+
+- Startup notification: The compositor may track wp_presenter interfaces
+  being created from the launcher side, and replied upon on the launchee
+  side. Compositors may also perform the application launcher role
+  themselves.
+
+- Focus stealing prevention: The compositor may know whether there is
+  recent user input that happened after the presentation request, and
+  ensure no disruptions happen.
+
+- Window raising/activation: The presented surface may be another 
previously
+  existing one, which might require bringing it to focus.
+
+A client that wishes to present another surface (of its own or from another
+client) will call wp_presentation_manager.create_presenter to create a
+presentation request. Compositors may use this object to track the source 
of
+the request in order to apply its policies when mapping the surface or
+bringing an existing one to focus.
+
+In the presented surface side, the request token will be notified upon
+through the wp_presentation_manager.acknowledge request. The method to pass
+the token across clients is considered an implementation detail, and is
+explicitly not observed here.
+
+Upon a successfully acknowledged presentation token,