Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
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
> + > + > + > + > + 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
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
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 in
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
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
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 composit
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
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 th
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
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
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 surf
Re: [RFC PATCH wayland-protocols] presentation: New protocol for presenting surfaces to the user
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
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