[RFC v2] Add Primary Selection Protocol Version 1

[Peter Hutterer]

On Sun, Jan 03, 2016 at 10:17:12PM -0800, Bill Spitzak wrote:
> 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.

this is still possible with the current proposal.
 
> 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).

your average touchpad sends events at 80hz. most of those translate into
some sort of pointer movement and wl_pointer events that are ignored by the
client unless they trigger something specific. even if you use a lot of
panning, I think we disagree on what "a lot" is in the context of input
events :)

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

in the normal use-case you will get a lot more focus changes than middle
clicks.

Cheers,
   Peter

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