On Mon, Jan 04, 2016 at 03:05:24PM +1000, Peter Hutterer wrote: > On Fri, Dec 18, 2015 at 12:03:46PM -0500, Lyude wrote: > > Signed-off-by: Lyude <cp...@redhat.com> > > --- > > Changes > > * Add new interfaces to replace reuse of wl_data_(source|offer) > > * Get rid of the selection changed event since we now have our own version > > of wl_data_(source|offer), and clients can just assume destroyed events > > indicate that their data in the primary clipboard has been replaced. > > * Get rid of summary on arguments, I noticed most of the official wayland > > protocol doesn't actually use these, and they were mostly redundant > > anyway. > > * s/selection_set/set_selection/ > > * Add destructor requests for all interfaces > > > > Makefile.am | 1 + > > unstable/primary-selection/README | 4 + > > .../primary-selection-unstable-v1.xml | 178 > > +++++++++++++++++++++ > > 3 files changed, 183 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 5926a41..582a49e 100644 > > --- a/Makefile.am > > +++ b/Makefile.am > > @@ -5,6 +5,7 @@ unstable_protocols = > > \ > > unstable/text-input/text-input-unstable-v1.xml > > \ > > unstable/input-method/input-method-unstable-v1.xml > > \ > > unstable/xdg-shell/xdg-shell-unstable-v5.xml > > \ > > + unstable/primary-selection/primary-selection-unstable-v1.xml > > \ > > $(NULL) > > > > nobase_dist_pkgdata_DATA = > > \ > > diff --git a/unstable/primary-selection/README > > b/unstable/primary-selection/README > > new file mode 100644 > > index 0000000..2dfce3d > > --- /dev/null > > +++ b/unstable/primary-selection/README > > @@ -0,0 +1,4 @@ > > +Primary selection protocol > > + > > +Maintainers: > > +Lyude <cp...@redhat.com> > > 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 0000000..32a4660 > > --- /dev/null > > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > > @@ -0,0 +1,178 @@ > > +<?xml version="1.0" encoding="UTF-8"?> > > + > > +<protocol name="primary_selection"> > > + <copyright> > > + 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. > > + </copyright> > > + > > + <interface name="zwp_primary_selection_device_manager_v1" version="1"> > > + <description summary="X primary selection emulation"> > > + Provides the ability to have a primary selection buffer to match > > that of > > there's confusion with the "buffer" vs "device". you create a device, but > then you read a buffer? why not create a buffer, or alternatively, why not > read from the device? > > > + the X server. This allows users to select bodies of text, and then > > paste > > + them in another buffer without having to do the initial paste. > > s/paste/copy/, right? > > > + > > + The primary buffer manager is in charge of handling client's > > requests to > > + indicate that text has been selection, along with handling client's > > access > > "has been selected" > "clients'" > > > > + to selected text. > > + </description> > > + > > + <request name="create_primary_selection_source"> > > + <description summary="create a new primary selection source"> > > + Create a new primary selection source. > > + </description> > > + <arg name="id" type="new_id" > > interface="zwp_primary_selection_source_v1"/> > > + </request> > > + > > + <request name="get_primary_selection_device"> > > + <description summary="primary selection device manager"> > > + Singleton global object that manages the > > zwp_primary_selection_device_v1 > > + objects for each wl_seat. > > + </description> > > + <arg name="id" type="new_id" > > interface="zwp_primary_selection_device_v1"/> > > + <arg name="seat" type="object" interface="wl_seat"/> > > + </request> > > + > > + <request name="destroy"> > > + <description summary="destroy the primary selection device manager"> > > + Destroy the primary selection device manager. > > + </description> > > + </request> > > + </interface> > > + > > + <interface name="zwp_primary_selection_device_v1" version="1"> > > + <request name="set_selection"> > > + <description summary="set the primary selection"> > > + Set the current contents of the primary selection buffer. This > > clears > > + anything which was previously held in the primary selection buffer. > > + > > + This request can only be used while the window is focused. > > you need to define what "can only be used" means here. Most likely "has no > effect unless", because the other option would be to send a protocol error > and be prone to race conditions if the focus changes while the request is > in-flight. > > And the issue with using "focused" as a term has been pointed out already, > it's safer to make this a compositor-specific policy/behaviour that may or > may not be tied to the window focus (which has separate touch, keyboard and > pointer foci anyway). If a middle-click triggers a focus change, the > compositor must arrange the events so that the order is wl_pointer.enter, > selection stuff, wl_pointer.button to make sure the focus is correct. > > > + </description> > > + <arg name="source" type="object" > > interface="zwp_primary_selection_source_v1"/> > > + </request> > > + > > + <event name="selection_offer"> > > + <description summary="primary selection buffer is ready for reading"> > > + Sent when the client has permission to read from the primary > > selection > > + buffer. > > + > > + This event is sent whenever the client receives a middle click, > > and will > > + be received by the client before the actual middle click event. > > While > > + the compositor is free to bind this event to another input event > > (such > > + as a keyboard shortcut), the client should always treat pastes > > from the > > s/pastes/selection_offer events/ > > > + primary selection as middle clicks. This is to ensure the behavior > > is > > + identical to that of primary selection pasting in X. > > Not a big fan of this, the intent is good but the wording needs improvement. > Unless you somehow pair the event with a middle click, a client cannot know > if the middle click triggered the paste or a keyboard shortcut, followed by > a middle click. I would argue for wording that requires this event to be in > the same wl_{pointer|touch|keyboard}.frame as the triggering event. > > Let's assume an application that binds middle click to full-screen, for > argument's sake: > "treat pastes from the primary selection as middle clicks." > This would mean that if you receive a selection_offer event the client must > full-screen the application because the event is to be treated like a > middle click :) > > Suggested rewording: > "This event is typically sent whenever the user executes a middle click > though the compositor may bind this event to other user input sequences. If > applicable, the selection_offer event is sent in the same wl_pointer.frame, > wl_touch.frame or wl_keyboard.frame as the triggering event. > > To ensure identical behavior to primary selection pasting in X, a client > should interpret a selection_offer event as paste event." > > > + > > + It is up to the client to decide whether or not it is appropriate > > to > > + read from the primary buffer and paste it's contents. > > iirc "whether" means you can skip "or not", it's superfluous. Not going to > fight over that though :) > > > + </description> > > + <arg name="offer" type="new_id" > > interface="zwp_primary_selection_offer_v1"/> > > + </event> > > + > > + <request name="destroy"> > > + <description summary="destroy the primary selection device"> > > + Destroy the primary selection device. > > + </description> > > + </request> > > + </interface> > > + > > + <interface name="zwp_primary_selection_offer_v1" version="1"> > > + <description summary="offer to transfer primary selection contents"> > > + A wp_primary_selection_offer represents an offer to transfer the > > contents > > + of the primary selection clipboard to the client. Similar to > > + wl_data_offer, the offer also describes the different mime types > > that the > > + data can be converted to and provides the mechanisms for > > transferring the > > + data directly to the client. > > + </description> > > + > > + <request name="receive"> > > + <description summary="request that the data is transferred"> > > + To transfer the contents of the primary selection clipboard, the > > client > > + issues this request and indicates the mime type that it wants to > > + receive. The transfer happens through the passed file descriptor > > + (typically created with the pipe system call). The source client > > writes > > + the data in the mime type representation requested and then closes > > the > > + file descriptor. > > + > > + The receiving client reads from the read end of the pipe until EOF > > and > > + closes its end, at which point the transfer is complete. > > "... and the selection offer should be destroyed." > > > + </description> > > + <arg name="mime_type" type="string"/> > > + <arg name="fd" type="fd"/> > > + </request> > > + > > + <request name="destroy"> > > + <description summary="destroy the primary selection offer"> > > + Destroy the primary selection offer. > > + </description> > > + </request> > > + > > + <event name="offer"> > > This needs a "mime"-related name, not an "offer", maybe > "mime_type_available" or so. also, in the tablet interface we just added a > "done" event, I think it's worth adding this to delineate the end of > available mime-types.
This name comes from the data device protocol from wayland.xml and I think it's better to keep them consistent even though the event/request name does not include "mime type". > > > + <description summary="advertise offered mime type"> > > + Sent immediately after creating the wp_primary_selection_offer > > object. > > + One event per offered mime type. > > s/offered/available/ > > > + </description> > > + <arg name="mime_type" type="string"/> > > + </event> > > + </interface> > > + > > + <interface name="zwp_primary_selection_source_v1" version="1"> > > + <description summary="offer to replace the contents of the primary > > selection"> > > + Similar to the relationship between a wl_data_offer and a > > wl_data_source > > + object, the wp_primary_selection_source object is the source side of > > + wp_primary_selection_offer, it provides a way to describe the offered > > + data and respond to requests to transfer the new contents of the > > primary > > + selection clipboard. > > + </description> > > + > > + <request name="offer"> > > "add_mime_type" would be a lot more expressive. Same as with the related event. This would make the protocol differ more from the one it is based upon. > > > + <description summary="add an offered mime type"> > > + This request adds a mime type to the set of mime types advertised > > to > > + targets. Can be called several times to offer multiple types. > > + </description> > > + <arg name="mime_type" type="string"/> > > + </request> > > + > > + <request name="destroy"> > > + <description summary="destroy the primary selection source"> > > + Destroy the primary selection source. > > + </description> > > + </request> > > + > > + <event name="send"> > > + <description summary="send the primary selection contents"> > > + Request for the current primary selection contents from the client. > > + Send the specified mime type over the passed file descriptor, then > > + close it. > > + </description> > > + <arg name="mime_type" type="string"/> > > + <arg name="fd" type="fd"/> > > + </event> > > + > > + <event name="cancelled"> > > + <description summary="request for primary selection contents was > > canceled"> > > + This primary selection source has been replaced by another primary > > + selection source. The client should clean up and destroy this > > primary > > + selection source. > > + </description> > > + </event> > > + </interface> > > +</protocol> > > I'm missing something or I'm misunderstanding how this is supposed to work. > When I highlight something, the source adds the mimetypes available. A middle > click triggers the selection_offer event and the "offer" events on that > object. the client calls "receive" which converts to the "send" event in the > other client and data is exchanged over the fd. > > Two problems: > * the source client has no way of finalising the list of mimetypes. What > happens if a mimetype is added after the selection_offer event was sent to > the receiving client? The source will complete its calls to .offer() before setting the selection. The .set_selection is the committing request. The offer will have received all .offer events before .selection_offer. > * what happens if the source client goes away between selection_offer and > the receiving client's receive? does the protocol guarantee an empty fd*? > I think you need a cancel event on the selection_offer object. Wouldn't wp_primary_selection_device.selection_offer(NULL) be the equivalent of a "cancel" of the offer? Jonas > > Cheers, > Peter > > * it probably needs to do that anyway, even if we add events. > _______________________________________________ > wayland-devel mailing list > wayland-devel@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/wayland-devel _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel