On Fri, 18 Oct 2019 00:56:38 +0200 Carlos Garnacho <carl...@gnome.org> 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 <carl...@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 <carl...@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 <carl...@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
pgpLyxcZH1HEo.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel