On 01/04/2016 08:33 PM, Peter Hutterer wrote:
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).
in the normal use-case you will get a lot more focus changes than middle
clicks.
Not if middle-click is used for panning. That's why I mentioned it.
You are correct though that it is probably irrelevant. Though I am a bit
concerned that this event includes an object with a new id, and all the
necessary work on both the compositor and client to track it.
one of the big benefits that input related stuff has is that you don't need
to care too much about resources. yes, this protocol involves creating and
destroying objects on every middle click. Compared to the textures you just
had to load to display the web browser, this is peanuts. Crushed into very
small pieces :)
Maybe it should only send the newid if the selection has changed. The
client can keep the old object around until it is destroyed, even if it
gets many clicks.
ie. when the selection changes, any old offers get the destroyed event.
But clients do not get the new offer until they get another middle
click. If the user clicks many times only one offer proxy is created.
The overhead may not be so minimal in creating/destroying local objects
in some languages such as Python, so it does seem nice to avoid this. A
bigger concern is that if more events are decided to be "pasteable" by
the compostior, it will have to send the offer even more times (imagine
if it is decided that any keystroke can paste). This rule means it only
has to send it before the first such event.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
