[RFC v2] Add Primary Selection Protocol Version 1

[Michal Suchanek]

On 18 December 2015 at 20:34, Bill Spitzak <spitzak at gmail.com> wrote:
>
>
> 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.

So when a window is once clicked it can from then on arbitrarily set
primary selection?

Or is there a timeout? How long?

You cannot possibly tie the setting of the selection to a particular
click. I mean the user does something, as a result the application
gets an event, the application processes the event, and as a result it
finds out it would be a good idea to set the selection. Where does the
fact that the user clicked the window sometime in the past help when
the request to set the selection actually arrives?

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

Same. If setting selection should not require focus why pulling the
selection should?

If middle-clicking a window is encouraged to perform a paste and it is
not encouraged to imply that the middle click did anything to the
window focus then it is advisable to not depend on focus state for
pasting.

The thing with focus here is probably meant to add some security so
that some arbitrary applications do not use the primary paste buffer
for exchanging arbitrary data without any user action.

As pointed out focus cannot be relied on to be of any value for
determining copy and paste ability.

so there are a few options here

1) find a flag that *can* be relied on to set copy and paste
capability - something that is user-visible and user-controlled and
does not get into the way of usual copy and paste workflow

2) just say that primary selection is inherently insecure and allow
free access to most applications possibly excluding some applications
which are deemed untrusted - pretty much current X situation

3) control the copy and paste in compositor or dedicated paste manager
- the application can only get access to paste buffer in response to a
paste event which it gets from outside. Then the binding of input
events is indeed not determined by the application but by the
compositor.

In this case
 - even if middle click is the default event that triggers a paste it
should not be part of the specification that it's a middle click. Any
input event can trigger a paste event.
 - the paste event should reference the input event in question so
that the application can ignore the input even if it decides to handle
the paste event.

Thanks

Michal