Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > From: Lyude > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to it wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Lyude > Signed-off-by: Carlos Garnacho > --- > After having talked with Lyude, I'll be trying to move this ahead. I'm glad to see this work continuing and hope we'll see a v5 soon? > Changes since v3: > - Added a rather verbose protocol description, including a > high-level overview of the workings. > - Made event emission 1:1 with wayland core protocol selections, > wp_primary_selection_offer.offer events are now expected to be > emitted between wp_primary_data_device.data_offer and > wp_primary_data_device.selection > - Improved wording here and there. > - Added serial argument to wp_primary_data_offer.receive that can be > used to match against recent events. > > > Makefile.am| 1 + > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 229 > + > 3 files changed, 234 insertions(+) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..eefa20f 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/primary-selection/primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..6d8c0c6 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Lyude > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..a3618d5 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,229 @@ > + > + > + > +Copyright © 2015 Red Hat > + > +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. > + I want to give just a few general comments on the overall text, and a couple more tangible suggestions below. I'm glad to see this is being developed in a generalized fashion that doesn't specify what input operations are used. For example, on my laptop there isn't a 'middle mouse button' and synthesizing it by L+R clicks is cumbersome, so I configure primary selection paste to occur with a keyboard combo. It looks like nothing in this protocol would prohibit that, and compositors make the input operations easily customizable. This protocol references the X protocol in a number of places. Thinking to the future, I wonder if perhaps our future readers will be a lot less familiar with X (assuming we're successful here), so perhaps some of these references could be minimalized. E.g. imagine the reader is an Android or iPhone developer unfamiliar with X intricacies. That said, if you do want to reference the X protocol, it would be useful to highlight where this protocol behaves differently than X. (That is, if it does differ... I'm not familiar enough with X selection in
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On 24 February 2016 at 10:54, Jonas Ådahl wrote: > On Wed, Feb 24, 2016 at 10:25:19AM +0100, Michal Suchanek wrote: >> On 24 February 2016 at 05:33, Jonas Ådahl wrote: >> > On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: >> >> From: Lyude >> >> >> >> This primary selection is similar in spirit to the eponimous >> >> in X11, allowing a quick "select text + middle click" shortcut >> >> to copying and pasting. >> >> >> >> It's otherwise very similar to it wayland counterpart, and >> >> explicitly made consistent with it. >> >> >> >> Signed-off-by: Lyude >> >> Signed-off-by: Carlos Garnacho >> >> --- >> >> After having talked with Lyude, I'll be trying to move this ahead. >> >> >> >> Changes since v3: >> >> - Added a rather verbose protocol description, including a >> >> high-level overview of the workings. >> >> - Made event emission 1:1 with wayland core protocol selections, >> >> wp_primary_selection_offer.offer events are now expected to be >> >> emitted between wp_primary_data_device.data_offer and >> >> wp_primary_data_device.selection >> >> - Improved wording here and there. >> >> - Added serial argument to wp_primary_data_offer.receive that can be >> >> used to match against recent events. >> >> >> >> >> >> Makefile.am| 1 + >> >> unstable/primary-selection/README | 4 + >> >> .../primary-selection-unstable-v1.xml | 229 >> >> + >> >> 3 files changed, 234 insertions(+) >> >> create mode 100644 unstable/primary-selection/README >> >> create mode 100644 >> >> unstable/primary-selection/primary-selection-unstable-v1.xml >> >> >> >> diff --git a/Makefile.am b/Makefile.am >> >> index 57d0023..eefa20f 100644 >> >> --- a/Makefile.am >> >> +++ b/Makefile.am >> >> @@ -7,6 +7,7 @@ unstable_protocols = >> >> \ >> >> unstable/xdg-shell/xdg-shell-unstable-v5.xml >> >> \ >> >> unstable/relative-pointer/relative-pointer-unstable-v1.xml >> >> \ >> >> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml >> >> \ >> >> + unstable/primary-selection/primary-selection-unstable-v1.xml >> >> \ >> >> $(NULL) >> >> >> >> stable_protocols = >> >> \ >> >> diff --git a/unstable/primary-selection/README >> >> b/unstable/primary-selection/README >> >> new file mode 100644 >> >> index 000..6d8c0c6 >> >> --- /dev/null >> >> +++ b/unstable/primary-selection/README >> >> @@ -0,0 +1,4 @@ >> >> +Primary selection protocol >> >> + >> >> +Maintainers: >> >> +Lyude >> >> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml >> >> b/unstable/primary-selection/primary-selection-unstable-v1.xml >> >> new file mode 100644 >> >> index 000..a3618d5 >> >> --- /dev/null >> >> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml >> >> @@ -0,0 +1,229 @@ >> >> + >> >> + >> >> + >> >> +Copyright © 2015 Red Hat >> >> + >> >> +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 protocol provides the ability to have a primary selection >> >> device to >> >> +match that of the X server. This primary selection is a shortcut to >> >> the >> >> +common clipboard selection, where text just needs to be selected in >> >> order >> >> +to allow copying it elsewhere. The de facto way to perform this >> >> action >> >> +is the middle mouse button, although it is not limited to this one. >> >> + >> >> +Clients wishing to honor primary selection should create a primary
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > From: Lyude > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to it wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Lyude > Signed-off-by: Carlos Garnacho > --- > After having talked with Lyude, I'll be trying to move this ahead. > > Changes since v3: > - Added a rather verbose protocol description, including a > high-level overview of the workings. > - Made event emission 1:1 with wayland core protocol selections, > wp_primary_selection_offer.offer events are now expected to be > emitted between wp_primary_data_device.data_offer and > wp_primary_data_device.selection > - Improved wording here and there. > - Added serial argument to wp_primary_data_offer.receive that can be > used to match against recent events. > > > Makefile.am| 1 + > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 229 > + > 3 files changed, 234 insertions(+) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..eefa20f 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/primary-selection/primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..6d8c0c6 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Lyude > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..a3618d5 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,229 @@ > + > + > + > +Copyright © 2015 Red Hat > + > +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 protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer events > +to let know of the mime types being offered. > + > +When the primary sele
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On Wed, Feb 24, 2016 at 10:25:19AM +0100, Michal Suchanek wrote: > On 24 February 2016 at 05:33, Jonas Ådahl wrote: > > On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > >> From: Lyude > >> > >> This primary selection is similar in spirit to the eponimous > >> in X11, allowing a quick "select text + middle click" shortcut > >> to copying and pasting. > >> > >> It's otherwise very similar to it wayland counterpart, and > >> explicitly made consistent with it. > >> > >> Signed-off-by: Lyude > >> Signed-off-by: Carlos Garnacho > >> --- > >> After having talked with Lyude, I'll be trying to move this ahead. > >> > >> Changes since v3: > >> - Added a rather verbose protocol description, including a > >> high-level overview of the workings. > >> - Made event emission 1:1 with wayland core protocol selections, > >> wp_primary_selection_offer.offer events are now expected to be > >> emitted between wp_primary_data_device.data_offer and > >> wp_primary_data_device.selection > >> - Improved wording here and there. > >> - Added serial argument to wp_primary_data_offer.receive that can be > >> used to match against recent events. > >> > >> > >> Makefile.am| 1 + > >> unstable/primary-selection/README | 4 + > >> .../primary-selection-unstable-v1.xml | 229 > >> + > >> 3 files changed, 234 insertions(+) > >> create mode 100644 unstable/primary-selection/README > >> create mode 100644 > >> unstable/primary-selection/primary-selection-unstable-v1.xml > >> > >> diff --git a/Makefile.am b/Makefile.am > >> index 57d0023..eefa20f 100644 > >> --- a/Makefile.am > >> +++ b/Makefile.am > >> @@ -7,6 +7,7 @@ unstable_protocols = > >>\ > >> unstable/xdg-shell/xdg-shell-unstable-v5.xml > >>\ > >> unstable/relative-pointer/relative-pointer-unstable-v1.xml > >>\ > >> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > >>\ > >> + unstable/primary-selection/primary-selection-unstable-v1.xml > >>\ > >> $(NULL) > >> > >> stable_protocols = > >>\ > >> diff --git a/unstable/primary-selection/README > >> b/unstable/primary-selection/README > >> new file mode 100644 > >> index 000..6d8c0c6 > >> --- /dev/null > >> +++ b/unstable/primary-selection/README > >> @@ -0,0 +1,4 @@ > >> +Primary selection protocol > >> + > >> +Maintainers: > >> +Lyude > >> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > >> b/unstable/primary-selection/primary-selection-unstable-v1.xml > >> new file mode 100644 > >> index 000..a3618d5 > >> --- /dev/null > >> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > >> @@ -0,0 +1,229 @@ > >> + > >> + > >> + > >> +Copyright © 2015 Red Hat > >> + > >> +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 protocol provides the ability to have a primary selection device > >> to > >> +match that of the X server. This primary selection is a shortcut to > >> the > >> +common clipboard selection, where text just needs to be selected in > >> order > >> +to allow copying it elsewhere. The de facto way to perform this action > >> +is the middle mouse button, although it is not limited to this one. > >> + > >> +Clients wishing to honor primary selection should create a primary > >> +selection source and set it as the selection through > >> +wp_primary_selection_device.set_selection whenever the text selection > >> +changes. In order to minim
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On 24 February 2016 at 05:33, Jonas Ådahl wrote: > On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: >> From: Lyude >> >> This primary selection is similar in spirit to the eponimous >> in X11, allowing a quick "select text + middle click" shortcut >> to copying and pasting. >> >> It's otherwise very similar to it wayland counterpart, and >> explicitly made consistent with it. >> >> Signed-off-by: Lyude >> Signed-off-by: Carlos Garnacho >> --- >> After having talked with Lyude, I'll be trying to move this ahead. >> >> Changes since v3: >> - Added a rather verbose protocol description, including a >> high-level overview of the workings. >> - Made event emission 1:1 with wayland core protocol selections, >> wp_primary_selection_offer.offer events are now expected to be >> emitted between wp_primary_data_device.data_offer and >> wp_primary_data_device.selection >> - Improved wording here and there. >> - Added serial argument to wp_primary_data_offer.receive that can be >> used to match against recent events. >> >> >> Makefile.am| 1 + >> unstable/primary-selection/README | 4 + >> .../primary-selection-unstable-v1.xml | 229 >> + >> 3 files changed, 234 insertions(+) >> create mode 100644 unstable/primary-selection/README >> create mode 100644 >> unstable/primary-selection/primary-selection-unstable-v1.xml >> >> diff --git a/Makefile.am b/Makefile.am >> index 57d0023..eefa20f 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -7,6 +7,7 @@ unstable_protocols = >> \ >> unstable/xdg-shell/xdg-shell-unstable-v5.xml >> \ >> unstable/relative-pointer/relative-pointer-unstable-v1.xml >> \ >> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml >> \ >> + unstable/primary-selection/primary-selection-unstable-v1.xml >> \ >> $(NULL) >> >> stable_protocols = >> \ >> diff --git a/unstable/primary-selection/README >> b/unstable/primary-selection/README >> new file mode 100644 >> index 000..6d8c0c6 >> --- /dev/null >> +++ b/unstable/primary-selection/README >> @@ -0,0 +1,4 @@ >> +Primary selection protocol >> + >> +Maintainers: >> +Lyude >> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml >> b/unstable/primary-selection/primary-selection-unstable-v1.xml >> new file mode 100644 >> index 000..a3618d5 >> --- /dev/null >> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml >> @@ -0,0 +1,229 @@ >> + >> + >> + >> +Copyright © 2015 Red Hat >> + >> +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 protocol provides the ability to have a primary selection device to >> +match that of the X server. This primary selection is a shortcut to the >> +common clipboard selection, where text just needs to be selected in >> order >> +to allow copying it elsewhere. The de facto way to perform this action >> +is the middle mouse button, although it is not limited to this one. >> + >> +Clients wishing to honor primary selection should create a primary >> +selection source and set it as the selection through >> +wp_primary_selection_device.set_selection whenever the text selection >> +changes. In order to minimize calls in pointer-driven text selection, >> +it should happen only once after the operation finished. Similarly, >> +a NULL source should be set when text is unselected. >> + >> +wp_primary_selection_offer objects are first announced through the >> +wp_primary_selection_device.data_offer event. Immediately after this
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > From: Lyude > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to it wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Lyude > Signed-off-by: Carlos Garnacho > --- > After having talked with Lyude, I'll be trying to move this ahead. > > Changes since v3: > - Added a rather verbose protocol description, including a > high-level overview of the workings. > - Made event emission 1:1 with wayland core protocol selections, > wp_primary_selection_offer.offer events are now expected to be > emitted between wp_primary_data_device.data_offer and > wp_primary_data_device.selection > - Improved wording here and there. > - Added serial argument to wp_primary_data_offer.receive that can be > used to match against recent events. > > > Makefile.am| 1 + > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 229 > + > 3 files changed, 234 insertions(+) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..eefa20f 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/primary-selection/primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..6d8c0c6 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Lyude > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..a3618d5 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,229 @@ > + > + > + > +Copyright © 2015 Red Hat > + > +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 protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer events > +to let know of the mime types being offered. > + > +When the primary sele
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On 23 February 2016 at 20:03, Bill Spitzak wrote: > > > On Tue, Feb 23, 2016 at 1:32 AM, Michal Suchanek wrote: >> >> On 22 February 2016 at 19:23, Carlos Garnacho wrote: >> >> > Right, that's why I suggest having those reunited in a single logical >> > focus. Anything else is plagued of corner cases. >> >> That's totally not going to work. When you have multiple touch panels >> you can touch multiple places. Are you proposing that on whichever >> panel you happen to touch first locks the other panel from working or >> on whichever panel you touch last steals the touch on the earlier >> panel? >> >> I do not think either is expected behaviour. > > > What? Absolutely this is the expected behavior. All the touch events go to > the same client as the first touch event. For a more obvioius example, > keystrokes and modifier states need to be sent to the client that you are > pressing a mouse button on, even if the "keyboard focus" is some other > client. There is only one focus for every single thing in the seat, the > thing you are calling the "keyboard focus" is just a helper for what that > focus is when no mouse buttons are held down. > > If you want them to go to different clients, put the touch panels on > different seats. > > I fully agree that having "number of focus" != "number of seats" is going to > be plagued with corner cases. > >> > Citation needed :). Windows can be certainly arranged so that it's not >> > possible to move the pointer between app A and B without going through >> > a third application. The problem with doing this on pointer focus is >> >> That can happen only with relative axis. With absolute axis you can >> point anywhere anytime without going through anywhere else. Let's say >> that for the sake of rodent users it is better to consider entry and >> motion events insignificant. > > > Who cares that it can't happen for absolute axis. It does happen for > relative and those exist, even if you personally don't own a mouse. > >> > What is unreasonable about serial checking? >> >> How is the serial related to the paste? How is the application >> supposed to pick serial so it can receive the paste? You can pick the >> event which triggers the paste in the application logic. Will that >> mean that when compositor fails to check events from a device (or the >> application uses a device exclusively and possibly directly drives the >> hardware) binding to some buttons will work and binding to other >> buttons will fail? > > > It's really easy: the client sends the event it thinks triggered the paste. > The compositor checks to make sure it is an event that really existed and > that it counts as some active user interaction (ie it is a mouse or keyboard > click). If the client sends a fake event or a focus-in event or anything > else the compositor does not like, it will not get access to the clipboard > data. > > The entire point of this is so that it would be possible to put sensitive > data into the selection, because client cannot look at it without the user > doing something obvious, such as clicking. Moving the mouse around should > not cause clients to be able to look at the selection. > >> > Let's take the most extreme case, primary selection can be broadcasted >> > and clients can be free to read data right away. You've just allowed >> > compositors to replicate all the flaws of X11 primary selection. >> >> And you have allowed all the legacy X11 clients to perform flawlessly. > > > Except that the user has to be careful to not select passwords or banking > numbers or anything else sensitive. > >> So it's fine to suggest reasonable default policy for compositor >> implementors but it's also fine to allow for different policies. >> >> I would not mandate broadcasting the selection changes >> indiscriminately. However, if people are concerned about applications >> that listen for the broadcasts in X11 land it should be possible to >> set up special policy for them so they can receive the broadcasts in >> Wayland as well. Similarly when an application is supposed to run >> sandboxed and there is enough concern about information leak through >> clipboard it should be possible to set up a policy for it to never >> receive selection offers. > > > It sounds like you are basically saying "paste does not work unless the > client is specially privileged". You are saying that also. You say that the client must have keyboard focus to receive pastes. What I add is that different policies might be viable and useful and the protocol should not preclude the compositor from using different policies. > > The reason for the serial is so that the compositor can decide whether to > honor a request for the clipboard. You can still have specially privileged > clients that can get it for any event, this is for "normal" clients so that > paste works. And since there is already policy in place that gives client(s) the privilege to receive pastes it is redundant to check a client-supplied random in
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On 22 February 2016 at 19:23, Carlos Garnacho wrote: > Hi Michal, > > On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek wrote: >> On 22 February 2016 at 15:57, Carlos Garnacho wrote: >>> Hi Michal, >>> >>> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote: Hello, On 20 February 2016 at 01:31, Carlos Garnacho wrote: > + > + > +This protocol provides the ability to have a primary selection > device to > +match that of the X server. This primary selection is a shortcut to > the > +common clipboard selection, where text just needs to be selected in > order > +to allow copying it elsewhere. The de facto way to perform this > action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer > events > +to let know of the mime types being offered. > + > +When the primary selection changes, the client with the keyboard > focus > +will receive wp_primary_selection_device.selection events. Only the > client Why keyboard focus? Since paste is done mainly using mouse this has nothing to do with keyboard focus. >>> >>> Doing this so allows us to behave just the same than we do with the >>> core protocol selection, slightly divergent protocols make sharing >>> code harder. >>> >>> Conceptually, it also makes some sense to me. I argue that a logical >>> "key" focus is needed in compositors, even on lack of wl_keyboard >>> capabilities. Things that IMO make sense to tie together in this >>> focus, per-seat are: >>> - wl_keyboard focus >>> - wp_text_input focus >>> - focus por (possibly several) pads/buttonsets >>> - clipboard selection >>> - primary selection >>> >>> Of course these are only guidelines, and compositors may attempt to >>> implement split foci for these. But still, selection should be tied to >>> some definite focus, the other option is broadcasting, and I'd very >>> much prefer not to do that. >>> >>> I may try to change the wording just to suggest it's loosely attached >>> to keyboard focus though. >> >> If you put an Insert sticker on your pad button and bind pasting to >> that pad button and the pad focus is not tied to keyboard focus you >> have potentially a problem there. > > Right, that's why I suggest having those reunited in a single logical > focus. Anything else is plagued of corner cases. That's totally not going to work. When you have multiple touch panels you can touch multiple places. Are you proposing that on whichever panel you happen to touch first locks the other panel from working or on whichever panel you touch last steals the touch on the earlier panel? I do not think either is expected behaviour. > >> >>> > +with the keyboard focus will receive such events with a non-NULL > +wp_primary_selection_offer. Across keyboard focus changes, previously > +focused clients will receive wp_primary_selection_device.events with > a > +NULL wp_primary_selection_offer. > + > +In order to request the primary selection data, the client must pass > +a recent serial pertaining to the press event that is triggering the > +operation, if the compositor deems the serial valid and recent, the Why press event when it has an offer event to base the request on? There is no need to involve other unrelated events. >>> >>> IIRC The first protocol drafts attempted to limit the circumstances in >>> which a client could read the primary selection. This is a change of >>> approach. >>> IMHO the fact that the application receives ANY input event suffices. eg. a pointer entry event. >>> >>> Do you mean wl_pointer.enter should be enough to have the application >>> read the primary selection? seems open to data leaks to me. >>> >>> This serial event is meant to check for user interaction rather than >>> "any input event", so just focusing a client is not enough to have it >>> retrieve the primary selection. >> >> And why is clicking enough and focusing not? >> >> Accidentally clicking an application can happen as much as >> accidentally pointing at it. > > Citation needed :). Windows can be certainly arranged so that it's not > possible to
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
Hi Michal, On Mon, Feb 22, 2016 at 4:53 PM, Michal Suchanek wrote: > On 22 February 2016 at 15:57, Carlos Garnacho wrote: >> Hi Michal, >> >> On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote: >>> Hello, >>> >>> On 20 February 2016 at 01:31, Carlos Garnacho wrote: >>> + + +This protocol provides the ability to have a primary selection device to +match that of the X server. This primary selection is a shortcut to the +common clipboard selection, where text just needs to be selected in order +to allow copying it elsewhere. The de facto way to perform this action +is the middle mouse button, although it is not limited to this one. + +Clients wishing to honor primary selection should create a primary +selection source and set it as the selection through +wp_primary_selection_device.set_selection whenever the text selection +changes. In order to minimize calls in pointer-driven text selection, +it should happen only once after the operation finished. Similarly, +a NULL source should be set when text is unselected. + +wp_primary_selection_offer objects are first announced through the +wp_primary_selection_device.data_offer event. Immediately after this event, +the primary data offer will emit wp_primary_selection_offer.offer events +to let know of the mime types being offered. + +When the primary selection changes, the client with the keyboard focus +will receive wp_primary_selection_device.selection events. Only the client >>> >>> Why keyboard focus? >>> >>> Since paste is done mainly using mouse this has nothing to do with >>> keyboard focus. >> >> Doing this so allows us to behave just the same than we do with the >> core protocol selection, slightly divergent protocols make sharing >> code harder. >> >> Conceptually, it also makes some sense to me. I argue that a logical >> "key" focus is needed in compositors, even on lack of wl_keyboard >> capabilities. Things that IMO make sense to tie together in this >> focus, per-seat are: >> - wl_keyboard focus >> - wp_text_input focus >> - focus por (possibly several) pads/buttonsets >> - clipboard selection >> - primary selection >> >> Of course these are only guidelines, and compositors may attempt to >> implement split foci for these. But still, selection should be tied to >> some definite focus, the other option is broadcasting, and I'd very >> much prefer not to do that. >> >> I may try to change the wording just to suggest it's loosely attached >> to keyboard focus though. > > If you put an Insert sticker on your pad button and bind pasting to > that pad button and the pad focus is not tied to keyboard focus you > have potentially a problem there. Right, that's why I suggest having those reunited in a single logical focus. Anything else is plagued of corner cases. > >> >>> +with the keyboard focus will receive such events with a non-NULL +wp_primary_selection_offer. Across keyboard focus changes, previously +focused clients will receive wp_primary_selection_device.events with a +NULL wp_primary_selection_offer. + +In order to request the primary selection data, the client must pass +a recent serial pertaining to the press event that is triggering the +operation, if the compositor deems the serial valid and recent, the >>> >>> Why press event when it has an offer event to base the request on? >>> >>> There is no need to involve other unrelated events. >> >> IIRC The first protocol drafts attempted to limit the circumstances in >> which a client could read the primary selection. This is a change of >> approach. >> >>> >>> IMHO the fact that the application receives ANY input event suffices. >>> eg. a pointer entry event. >> >> Do you mean wl_pointer.enter should be enough to have the application >> read the primary selection? seems open to data leaks to me. >> >> This serial event is meant to check for user interaction rather than >> "any input event", so just focusing a client is not enough to have it >> retrieve the primary selection. > > And why is clicking enough and focusing not? > > Accidentally clicking an application can happen as much as > accidentally pointing at it. Citation needed :). Windows can be certainly arranged so that it's not possible to move the pointer between app A and B without going through a third application. The problem with doing this on pointer focus is that situations like this come off the very nature of a 2D compositor. Tying this to user interaction kills most of the concerns here, the situation where the user accidentally clicks on an app that happens to be malicious and request the clipboard on any interaction should be unlikely enough, plus it'd make a lousy malicious app. > With touch interface it's pretty much the > same thing. Wit
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On 22 February 2016 at 15:57, Carlos Garnacho wrote: > Hi Michal, > > On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote: >> Hello, >> >> On 20 February 2016 at 01:31, Carlos Garnacho wrote: >> >>> + >>> + >>> +This protocol provides the ability to have a primary selection device >>> to >>> +match that of the X server. This primary selection is a shortcut to the >>> +common clipboard selection, where text just needs to be selected in >>> order >>> +to allow copying it elsewhere. The de facto way to perform this action >>> +is the middle mouse button, although it is not limited to this one. >>> + >>> +Clients wishing to honor primary selection should create a primary >>> +selection source and set it as the selection through >>> +wp_primary_selection_device.set_selection whenever the text selection >>> +changes. In order to minimize calls in pointer-driven text selection, >>> +it should happen only once after the operation finished. Similarly, >>> +a NULL source should be set when text is unselected. >>> + >>> +wp_primary_selection_offer objects are first announced through the >>> +wp_primary_selection_device.data_offer event. Immediately after this >>> event, >>> +the primary data offer will emit wp_primary_selection_offer.offer >>> events >>> +to let know of the mime types being offered. >>> + >>> +When the primary selection changes, the client with the keyboard focus >>> +will receive wp_primary_selection_device.selection events. Only the >>> client >> >> Why keyboard focus? >> >> Since paste is done mainly using mouse this has nothing to do with >> keyboard focus. > > Doing this so allows us to behave just the same than we do with the > core protocol selection, slightly divergent protocols make sharing > code harder. > > Conceptually, it also makes some sense to me. I argue that a logical > "key" focus is needed in compositors, even on lack of wl_keyboard > capabilities. Things that IMO make sense to tie together in this > focus, per-seat are: > - wl_keyboard focus > - wp_text_input focus > - focus por (possibly several) pads/buttonsets > - clipboard selection > - primary selection > > Of course these are only guidelines, and compositors may attempt to > implement split foci for these. But still, selection should be tied to > some definite focus, the other option is broadcasting, and I'd very > much prefer not to do that. > > I may try to change the wording just to suggest it's loosely attached > to keyboard focus though. If you put an Insert sticker on your pad button and bind pasting to that pad button and the pad focus is not tied to keyboard focus you have potentially a problem there. > >> >>> +with the keyboard focus will receive such events with a non-NULL >>> +wp_primary_selection_offer. Across keyboard focus changes, previously >>> +focused clients will receive wp_primary_selection_device.events with a >>> +NULL wp_primary_selection_offer. >>> + >>> +In order to request the primary selection data, the client must pass >>> +a recent serial pertaining to the press event that is triggering the >>> +operation, if the compositor deems the serial valid and recent, the >> >> Why press event when it has an offer event to base the request on? >> >> There is no need to involve other unrelated events. > > IIRC The first protocol drafts attempted to limit the circumstances in > which a client could read the primary selection. This is a change of > approach. > >> >> IMHO the fact that the application receives ANY input event suffices. >> eg. a pointer entry event. > > Do you mean wl_pointer.enter should be enough to have the application > read the primary selection? seems open to data leaks to me. > > This serial event is meant to check for user interaction rather than > "any input event", so just focusing a client is not enough to have it > retrieve the primary selection. And why is clicking enough and focusing not? Accidentally clicking an application can happen as much as accidentally pointing at it. With touch interface it's pretty much the same thing. With click-to-focus also. If you want to prevent data leaks you can unmap windows that should not receive the paste or use a compositor with per-application access policy for clipboards. So instead of saying that a button down event should trigger paste in the protocol specification it is wiser to say that sending the paste offer to a client can happen at the discretion of the compositor and suggest some reasonable policy. Compositor should be free to implement any policy the author finds reasonable including broadcast on selection change, point to paste, button press to paste, and per-application different policies. > >> >> Otherwise you are going to have very fragile protocol that often fails >> because the application did not happen to receive whatever even is >> requested by the protocol. > > Note that it just mentions a press event, but
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
Hi Michal, On Mon, Feb 22, 2016 at 2:25 PM, Michal Suchanek wrote: > Hello, > > On 20 February 2016 at 01:31, Carlos Garnacho wrote: > >> + >> + >> +This protocol provides the ability to have a primary selection device to >> +match that of the X server. This primary selection is a shortcut to the >> +common clipboard selection, where text just needs to be selected in >> order >> +to allow copying it elsewhere. The de facto way to perform this action >> +is the middle mouse button, although it is not limited to this one. >> + >> +Clients wishing to honor primary selection should create a primary >> +selection source and set it as the selection through >> +wp_primary_selection_device.set_selection whenever the text selection >> +changes. In order to minimize calls in pointer-driven text selection, >> +it should happen only once after the operation finished. Similarly, >> +a NULL source should be set when text is unselected. >> + >> +wp_primary_selection_offer objects are first announced through the >> +wp_primary_selection_device.data_offer event. Immediately after this >> event, >> +the primary data offer will emit wp_primary_selection_offer.offer events >> +to let know of the mime types being offered. >> + >> +When the primary selection changes, the client with the keyboard focus >> +will receive wp_primary_selection_device.selection events. Only the >> client > > Why keyboard focus? > > Since paste is done mainly using mouse this has nothing to do with > keyboard focus. Doing this so allows us to behave just the same than we do with the core protocol selection, slightly divergent protocols make sharing code harder. Conceptually, it also makes some sense to me. I argue that a logical "key" focus is needed in compositors, even on lack of wl_keyboard capabilities. Things that IMO make sense to tie together in this focus, per-seat are: - wl_keyboard focus - wp_text_input focus - focus por (possibly several) pads/buttonsets - clipboard selection - primary selection Of course these are only guidelines, and compositors may attempt to implement split foci for these. But still, selection should be tied to some definite focus, the other option is broadcasting, and I'd very much prefer not to do that. I may try to change the wording just to suggest it's loosely attached to keyboard focus though. > >> +with the keyboard focus will receive such events with a non-NULL >> +wp_primary_selection_offer. Across keyboard focus changes, previously >> +focused clients will receive wp_primary_selection_device.events with a >> +NULL wp_primary_selection_offer. >> + >> +In order to request the primary selection data, the client must pass >> +a recent serial pertaining to the press event that is triggering the >> +operation, if the compositor deems the serial valid and recent, the > > Why press event when it has an offer event to base the request on? > > There is no need to involve other unrelated events. IIRC The first protocol drafts attempted to limit the circumstances in which a client could read the primary selection. This is a change of approach. > > IMHO the fact that the application receives ANY input event suffices. > eg. a pointer entry event. Do you mean wl_pointer.enter should be enough to have the application read the primary selection? seems open to data leaks to me. This serial event is meant to check for user interaction rather than "any input event", so just focusing a client is not enough to have it retrieve the primary selection. > > Otherwise you are going to have very fragile protocol that often fails > because the application did not happen to receive whatever even is > requested by the protocol. Note that it just mentions a press event, but does no mention of the interface/device it comes from. It can be the serial received on wl_pointer.button, wl_keyboard.key, wl_touch.down, wp_tablet_tool.down, ... compositors should ideally check all input interfaces. > > It's even worse with the keyboard focus. If the event that triggers > the paste also triggers getting keyboard focus you are going to have > protocol open to all kind of ugly race conditions. If it does not > trigger getting the keyboard focus the paste just fails. Where do you see race conditions? Because focus is handled by the compositor before event emission, AFAICT the client would receive the following event sequence: --> wl_keyboard.enter wl_data_device.data_offer wl_data_offer.offer [...] wl_data_device.selection zwp_primary_selection_device_v1.data_offer zwp_primary_selection_offer_v1.offer [...] zwp_primary_selection_device_v1.selection wl_pointer.button (..., serial_you_want_to_pass) <-- zwp_primary_selection_offer_v1.receive (..., serial_you_want_to_pass) Which results in the expected action to take place. > > There are point-to-type and click-to-type keyboard focus models which > should be both supported by the primary s
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
Hello, On 20 February 2016 at 01:31, Carlos Garnacho wrote: > + > + > +This protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. > + > +wp_primary_selection_offer objects are first announced through the > +wp_primary_selection_device.data_offer event. Immediately after this > event, > +the primary data offer will emit wp_primary_selection_offer.offer events > +to let know of the mime types being offered. > + > +When the primary selection changes, the client with the keyboard focus > +will receive wp_primary_selection_device.selection events. Only the > client Why keyboard focus? Since paste is done mainly using mouse this has nothing to do with keyboard focus. > +with the keyboard focus will receive such events with a non-NULL > +wp_primary_selection_offer. Across keyboard focus changes, previously > +focused clients will receive wp_primary_selection_device.events with a > +NULL wp_primary_selection_offer. > + > +In order to request the primary selection data, the client must pass > +a recent serial pertaining to the press event that is triggering the > +operation, if the compositor deems the serial valid and recent, the Why press event when it has an offer event to base the request on? There is no need to involve other unrelated events. IMHO the fact that the application receives ANY input event suffices. eg. a pointer entry event. Otherwise you are going to have very fragile protocol that often fails because the application did not happen to receive whatever even is requested by the protocol. It's even worse with the keyboard focus. If the event that triggers the paste also triggers getting keyboard focus you are going to have protocol open to all kind of ugly race conditions. If it does not trigger getting the keyboard focus the paste just fails. There are point-to-type and click-to-type keyboard focus models which should be both supported by the primary selection protocol. Thanks Michal ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
Hey Jonas, On Mon, Feb 22, 2016 at 8:53 AM, Jonas Ådahl wrote: > On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: >> From: Lyude >> >> This primary selection is similar in spirit to the eponimous >> in X11, allowing a quick "select text + middle click" shortcut >> to copying and pasting. >> >> It's otherwise very similar to it wayland counterpart, and >> explicitly made consistent with it. >> >> Signed-off-by: Lyude >> Signed-off-by: Carlos Garnacho >> --- >> After having talked with Lyude, I'll be trying to move this ahead. >> >> Changes since v3: >> - Added a rather verbose protocol description, including a >> high-level overview of the workings. >> - Made event emission 1:1 with wayland core protocol selections, >> wp_primary_selection_offer.offer events are now expected to be >> emitted between wp_primary_data_device.data_offer and >> wp_primary_data_device.selection >> - Improved wording here and there. >> - Added serial argument to wp_primary_data_offer.receive that can be >> used to match against recent events. > > > Overall good. Some comments inline. With those fixed, this is > Reviewed-by: Jonas Ådahl Thanks for the review! > >> >> >> Makefile.am| 1 + >> unstable/primary-selection/README | 4 + >> .../primary-selection-unstable-v1.xml | 229 >> + >> 3 files changed, 234 insertions(+) >> create mode 100644 unstable/primary-selection/README >> create mode 100644 >> unstable/primary-selection/primary-selection-unstable-v1.xml >> >> diff --git a/Makefile.am b/Makefile.am >> index 57d0023..eefa20f 100644 >> --- a/Makefile.am >> +++ b/Makefile.am >> @@ -7,6 +7,7 @@ unstable_protocols = >> \ >> unstable/xdg-shell/xdg-shell-unstable-v5.xml >> \ >> unstable/relative-pointer/relative-pointer-unstable-v1.xml >> \ >> unstable/pointer-constraints/pointer-constraints-unstable-v1.xml >> \ >> + unstable/primary-selection/primary-selection-unstable-v1.xml >> \ >> $(NULL) >> >> stable_protocols = >> \ >> diff --git a/unstable/primary-selection/README >> b/unstable/primary-selection/README >> new file mode 100644 >> index 000..6d8c0c6 >> --- /dev/null >> +++ b/unstable/primary-selection/README >> @@ -0,0 +1,4 @@ >> +Primary selection protocol >> + >> +Maintainers: >> +Lyude > > Any reason for the "anti-spam" thing here? The E-mail address is already > available all over the place anyway (commit author, commit body). > >> diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml >> b/unstable/primary-selection/primary-selection-unstable-v1.xml >> new file mode 100644 >> index 000..a3618d5 >> --- /dev/null >> +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml >> @@ -0,0 +1,229 @@ >> + >> + >> + >> +Copyright © 2015 Red Hat > > 2016 now as well? > >> + >> +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 protocol provides the ability to have a primary selection device to >> +match that of the X server. This primary selection is a shortcut to the >> +common clipboard selection, where text just needs to be selected in >> order >> +to allow copying it elsewhere. The de facto way to perform this action >> +is the middle mouse button, although it is not limited to this one. >> + >> +Clients wishing to honor primary selection should create a primary >> +selection source and set it as the selection through >> +wp_primary_selection_device.set_selection whenever the text selection >> +changes. In order to minimize calls in pointer-driven te
Re: [RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
On Sat, Feb 20, 2016 at 01:31:59AM +0100, Carlos Garnacho wrote: > From: Lyude > > This primary selection is similar in spirit to the eponimous > in X11, allowing a quick "select text + middle click" shortcut > to copying and pasting. > > It's otherwise very similar to it wayland counterpart, and > explicitly made consistent with it. > > Signed-off-by: Lyude > Signed-off-by: Carlos Garnacho > --- > After having talked with Lyude, I'll be trying to move this ahead. > > Changes since v3: > - Added a rather verbose protocol description, including a > high-level overview of the workings. > - Made event emission 1:1 with wayland core protocol selections, > wp_primary_selection_offer.offer events are now expected to be > emitted between wp_primary_data_device.data_offer and > wp_primary_data_device.selection > - Improved wording here and there. > - Added serial argument to wp_primary_data_offer.receive that can be > used to match against recent events. Overall good. Some comments inline. With those fixed, this is Reviewed-by: Jonas Ådahl > > > Makefile.am| 1 + > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 229 > + > 3 files changed, 234 insertions(+) > create mode 100644 unstable/primary-selection/README > create mode 100644 > unstable/primary-selection/primary-selection-unstable-v1.xml > > diff --git a/Makefile.am b/Makefile.am > index 57d0023..eefa20f 100644 > --- a/Makefile.am > +++ b/Makefile.am > @@ -7,6 +7,7 @@ unstable_protocols = > \ > unstable/xdg-shell/xdg-shell-unstable-v5.xml > \ > unstable/relative-pointer/relative-pointer-unstable-v1.xml > \ > unstable/pointer-constraints/pointer-constraints-unstable-v1.xml > \ > + unstable/primary-selection/primary-selection-unstable-v1.xml > \ > $(NULL) > > stable_protocols = > \ > diff --git a/unstable/primary-selection/README > b/unstable/primary-selection/README > new file mode 100644 > index 000..6d8c0c6 > --- /dev/null > +++ b/unstable/primary-selection/README > @@ -0,0 +1,4 @@ > +Primary selection protocol > + > +Maintainers: > +Lyude Any reason for the "anti-spam" thing here? The E-mail address is already available all over the place anyway (commit author, commit body). > diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml > b/unstable/primary-selection/primary-selection-unstable-v1.xml > new file mode 100644 > index 000..a3618d5 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,229 @@ > + > + > + > +Copyright © 2015 Red Hat 2016 now as well? > + > +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 protocol provides the ability to have a primary selection device to > +match that of the X server. This primary selection is a shortcut to the > +common clipboard selection, where text just needs to be selected in order > +to allow copying it elsewhere. The de facto way to perform this action > +is the middle mouse button, although it is not limited to this one. > + > +Clients wishing to honor primary selection should create a primary > +selection source and set it as the selection through > +wp_primary_selection_device.set_selection whenever the text selection > +changes. In order to minimize calls in pointer-driven text selection, > +it should happen only once after the operation finished. Similarly, > +a NULL source should be set when text is unselected. Does this mean that a client may not create one source object, and just kee
[RFC wayland-protocols v4] Add Primary Selection Protocol Version 1
From: Lyude This primary selection is similar in spirit to the eponimous in X11, allowing a quick "select text + middle click" shortcut to copying and pasting. It's otherwise very similar to it wayland counterpart, and explicitly made consistent with it. Signed-off-by: Lyude Signed-off-by: Carlos Garnacho --- After having talked with Lyude, I'll be trying to move this ahead. Changes since v3: - Added a rather verbose protocol description, including a high-level overview of the workings. - Made event emission 1:1 with wayland core protocol selections, wp_primary_selection_offer.offer events are now expected to be emitted between wp_primary_data_device.data_offer and wp_primary_data_device.selection - Improved wording here and there. - Added serial argument to wp_primary_data_offer.receive that can be used to match against recent events. Makefile.am| 1 + unstable/primary-selection/README | 4 + .../primary-selection-unstable-v1.xml | 229 + 3 files changed, 234 insertions(+) create mode 100644 unstable/primary-selection/README create mode 100644 unstable/primary-selection/primary-selection-unstable-v1.xml diff --git a/Makefile.am b/Makefile.am index 57d0023..eefa20f 100644 --- a/Makefile.am +++ b/Makefile.am @@ -7,6 +7,7 @@ unstable_protocols = \ unstable/xdg-shell/xdg-shell-unstable-v5.xml \ unstable/relative-pointer/relative-pointer-unstable-v1.xml \ unstable/pointer-constraints/pointer-constraints-unstable-v1.xml \ + unstable/primary-selection/primary-selection-unstable-v1.xml \ $(NULL) stable_protocols = \ diff --git a/unstable/primary-selection/README b/unstable/primary-selection/README new file mode 100644 index 000..6d8c0c6 --- /dev/null +++ b/unstable/primary-selection/README @@ -0,0 +1,4 @@ +Primary selection protocol + +Maintainers: +Lyude diff --git a/unstable/primary-selection/primary-selection-unstable-v1.xml b/unstable/primary-selection/primary-selection-unstable-v1.xml new file mode 100644 index 000..a3618d5 --- /dev/null +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml @@ -0,0 +1,229 @@ + + + +Copyright © 2015 Red Hat + +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 protocol provides the ability to have a primary selection device to +match that of the X server. This primary selection is a shortcut to the +common clipboard selection, where text just needs to be selected in order +to allow copying it elsewhere. The de facto way to perform this action +is the middle mouse button, although it is not limited to this one. + +Clients wishing to honor primary selection should create a primary +selection source and set it as the selection through +wp_primary_selection_device.set_selection whenever the text selection +changes. In order to minimize calls in pointer-driven text selection, +it should happen only once after the operation finished. Similarly, +a NULL source should be set when text is unselected. + +wp_primary_selection_offer objects are first announced through the +wp_primary_selection_device.data_offer event. Immediately after this event, +the primary data offer will emit wp_primary_selection_offer.offer events +to let know of the mime types being offered. + +When the primary selection changes, the client with the keyboard focus +will receive wp_primary_selection_device.selection events. Only the client +with the keyboard focus will receive such events with a non-NULL +wp_primary_selection_offer. Across keyboard focus changes, previously +focused clients w
