On 04/18/2015 07:53 AM, Carlos Garnacho wrote:
Let me try to correct this by removing some unnecessary data. In
particular no list of actions is sent by the destination. Also there is
no need for the compositor to echo the selected action back to the
destination. More importantly I have added "update the user interface"
requests from both source an destination, to make round-trips more clear
(this includes changing the cursor and changing graphics in the surfaces):
2. If handled purely by the dest:
wl_data_source compositor wl_data_offer
============== ========== =============
-> notify_actions
-> source_actions
action <-
update_ui <-
action <-
-> update_ui
...
(pointer moves across widgets)
action <-
update_ui <-
action <-
-> update_ui
...
(modifiers change)
-> modifiers
action <-
update_ui <-
action <-
-> update_ui
For reference here is your proposal. You seem to have added sending the
source actions to the destination and allowing that to edit the dest
action list, over what you originally proposed. I am not sure if this is
a copy+paste error or you actually mean it to be there, I marked it with
"new??"
wl_data_source compositor wl_data_offer
============== ========== =============
-> notify_actions
-> source_actions ### new??
notify_actions <-
action <- -> action
update_ui <-
-> update_ui
...
(pointer moves across widgets)
notify_actions <-
action <- -> action
update_ui <-
-> update_ui
...
(modifiers change)
action <- -> action
update_ui <-
-> update_ui
Options #1 and #2 involve roundtrips, option #3 doesn't.
Sorry I don't see this. I was going to say that they are exactly the
same, but I now see that #2 has one less round trip on the destination
side for the pointer-moved case (it can update the display
simultaneously with sending the selected action, while yours requires it
to wait for a response after sending the notify actions). So it wins there.
Though your version has the same number of round trips for
modifier-changed, they can be done simultaneously, while #2 requires
them to be done serially. So your version wins there.
I believe the mouse is moved more often than the modifiers are changed,
thus in total proposal #2 has fewer round trips.
Options #1
and #2 would still need some validation on the compositor to avoid
picking options unknown to either side.
Option 3 has to "validate" in that it has to do something if there is no
intersection of the lists. And I think you could consider the whole
"intersect the lists and choose based on modifier keys" a very large
"validation" function.
Not only that, I am pretty certain it would be harmless to send whatever
action the dest chose to the source without any checking at all, thus
the "validation" concern is moot. The source can check it pretty easily.
You are not saving anything as sources will have many other failure
modes (such as async deletion of the source data while the drag is
happening) and this is a trivial addition.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
