[RFC v2] Add Primary Selection Protocol Version 1

[Bill Spitzak]

On 01/03/2016 09:05 PM, Peter Hutterer wrote:
> On Fri, Dec 18, 2015 at 12:03:46PM -0500, Lyude wrote:
>> +        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.
>
> 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.

I really do not like this key assignment being something the compositor 
is in charge of. A client may have a very good reason to use 
middle-click for something else, yet still want the ability to paste 
from the selection.

Also it seems like you will send this on *every* middle click. Some 
clients require clicking the middle button a lot without pasting (it is 
very common to use it as a pan control in 2D/3D).

It seems like it would be much better to send this event when to 
surfaces with various foci (keyboard, mouse, etc) when the selection 
changes, and also when a surface gets a focus and the selection has 
changed since it last had focus.

> 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?
> * 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.

These problems apply to (and have been solved by?) the DnD offer objects 
already. Copy that exactly. If there is a bug it needs to be fixed in 
both of them.