[RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On Fri, Dec 18, 2015 at 9:03 AM, Lyude <cpaul at redhat.com> wrote:

> Signed-off-by: Lyude <cpaul at 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
>

I do not like the fact that a program has to create both a
wl_primary_selection_offer and a wl_data_offer on any selection (yes it can
defer the second one until the user starts a drag, but it still would be
nice to reuse the same one for both). Still not a huge problem, like in
many other cases the two proxies can be stuffed into the same higher-level
api object.

Some assurance that the abilities of both will be kept identical would
help, however. I don't want some data transfers to be impossible depending
on whether the user does dnd or middle-click paste.


> +    <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>
>

Also, looking at what happened to wl_pointer, it appears the design of
Wayland is to not have any "singletons" except the globally-advertised
objects. I'm not sure if this has any visible effects on your api because
there is no actual state stored on the object, and you must already support
creating more than one, but it might make sense to get rid of the words
"Singleton global".

+  <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.
> +      </description>
> +      <arg name="source" type="object"
> interface="zwp_primary_selection_source_v1"/>
> +    </request>
>

Please don't require the "window is focused". The rules used by the
compositor to accept/reject these offers should be defined by the
compositor (a possible rule is that the window either got a mouse click or
a keystroke from the seat). Clicking in a window should never be required
to cause focus/activate/raise by the low-level api, that is instead part of
the desktop and client definition.

+    <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
> +        primary selection as middle clicks. This is to ensure the
> behavior is
> +        identical to that of primary selection pasting in X.
> +
> +        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.
> +      </description>
> +      <arg name="offer" type="new_id"
> interface="zwp_primary_selection_offer_v1"/>
> +    </event>
>

I think it would be better to send this to the client when it gets any
focus from the seat, and also if the selection is changed while it has
focus. Then the client is able to free to use any method to do the paste
(though of course using the middle mouse is encouraged). Also means there
is not redundant events if the user clicks the middle mouse many times (a
lot of programs use the middle-mouse drag as a pan operation).

+    <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>
>

May want to point out that this can happen more than once (ie the middle
mouse button is clicked more than once per set_selection).

+    <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>
>

I would guess this event is also sent if the compositor refuses the
set_selection request?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20151218/4491a6db/attachment-0001.html>