Hi!, Chiming in late...
On Thu, Jan 7, 2016 at 3:50 AM, Lyude <cp...@redhat.com> wrote: > Signed-off-by: Lyude <cp...@redhat.com> > --- > > Notes: > Changes since V2 > * Bunch of grammatical/wording fixes from whot > * Addition of wp_primary_selection_offer::end_offers, for marking the end > of a > list of mime type offers > * selection_offers are no longer sent before an input event, and are sent > at the > first opportunity a client has to do a primary selection paste. This > decision > comes from a discussion with Jasper, where a couple of clients (such as > emacs) > were brought up that have their own bindings for primary selection > pasting. > Eventually I will probably work on adding some sort of paste_hint event > to > this so that the compositor can decide what keybinding triggers a > primary > selection paste, I agree with Jasper that it would be best to solve the > issue > of rebinding primary selection pastes after we have the basic protocol > for > primary selection worked out. > > Makefile.am | 1 + > unstable/primary-selection/README | 4 + > .../primary-selection-unstable-v1.xml | 176 > +++++++++++++++++++++ > 3 files changed, 181 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..057ba38 > --- /dev/null > +++ b/unstable/primary-selection/primary-selection-unstable-v1.xml > @@ -0,0 +1,176 @@ > +<?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 device to match that > of > + the X server. This allows users to select bodies of text, and then > paste > + them in another buffer without having to do the initial copy. > + > + The primary selection device manager is also in charge of handling > + client's requests to indicate that text has been selected, along with > + handling clients access 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> The name of these two requests feel a bit redundant, they end up in: zwp_primary_selection_device_manager_v1_create_primary_selection_source zwp_primary_selection_device_manager_v1_get_primary_selection_device "primary selection" is twice on both, and the functions are close to the 80 chars limit :). I'd suggest "create_source" and "get_device", the "primary selection" nature is already implicit in the protocol name/prefix, and the returned types. > + > + <request name="destroy" type="destructor"> > + <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. > + </description> > + <arg name="source" type="object" > interface="zwp_primary_selection_source_v1"/> wl_data_device.set_selection allows unsetting the current selection by passing NULL. I think it'd be worth allowing this too for the same reasons, clients might want to unset the selection (eg. gtk+ clears the primary selection when the client is the owner of the primary selection data and you unselect the text). This arg might need allow-null="true" then. > + </request> > + > + <event name="selection_offer"> > + <description summary="introduce a new wp_primary_selection_offer"> > + Similar to wl_data_device::data_offer, this event introduces a new > + wp_primary_selection_offer object that may be used to receive the > + current primary selection. Immediately folliwng this event, the new > + wp_primary_selection_offer object will send out > + wp_primary_selection_offer::offer events to describe the mime types > it > + offers. > + </description> > + <arg name="offer" type="new_id" > interface="zwp_primary_selection_offer_v1"/> > + </event> > + > + <request name="destroy" type="destructor"> > + <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. > + </description> > + <arg name="mime_type" type="string"/> > + <arg name="fd" type="fd"/> > + </request> > + > + <request name="destroy" type="destructor"> > + <description summary="destroy the primary selection offer"> > + Destroy the primary selection offer. > + </description> > + </request> > + > + <event name="offer"> > + <description summary="advertise offered mime type"> > + Sent immediately after creating the wp_primary_selection_offer > object. > + One event per offered mime type. > + </description> > + <arg name="mime_type" type="string"/> > + </event> > + > + <event name="end_offers"> > + <description summary="mark the end of the list of available mime > types"> > + Sent after we've send offer events for all of the available mime > types. > + </description> Here I see a slight difference with wl_data_device and wl_data_offer that would be great to even out, as it better allows clients to abstract wl_data_* and zwp_primary_selection_* in common interfaces. In zwp_primary_selection, you first receive a zwp_primary_selection_device_v1.selection_offer, and then this event in zwp_primary_selection_offer_v1, whereas in the wayland core protocol both the "offer introduction" and the "offer being put to use" events happen both on wl_data_device (.data_offer and .selection, respectively). This event can be maybe seen as belonging to the offer (it's state of the offer, at least), but I admit I'm more sold on the final event where you can start using the offer to be a device one. Cheers Carlos _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel