[RFC wayland-protocols V3] Add Primary Selection Protocol Version 1
Carlos Garnacho
carlosg at gnome.org
Thu Feb 4 18:26:59 UTC 2016
Hi!,
Chiming in late...
On Thu, Jan 7, 2016 at 3:50 AM, Lyude <cpaul at redhat.com> wrote:
> Signed-off-by: Lyude <cpaul at 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 <cpaul at 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
More information about the wayland-devel
mailing list