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.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
