Given it seems to me it's not clear how the additions in the spec would work i'll write an example here:
we have two apps, S (source) and T (target). S creates the wl_data_source, calls wl_data_source_offer with the supported mime types and calls wl_data_source_set_actions with one or more supported actions, using bitwise OR. T gets the wl_data_offer, the wl_data_offer_offer events and the wl_data_offer_actions with the actions set by wl_data_source_set_actions. T gets the drop event. T asks for the data and calls wl_data_offer_accept_action with one of the supported actions, or the ignore action. After this, after the server gets the accepted action, the wl_data_source would need to be notified, by wl_data_source_dropped, which carries the accepted action with it. In QtWayland i can now exit the loop and give the accepted action to Qt. But before doing that T calls wl_data_offer_finish which calls wl_data_source_cancel on S's wl_data_source so it can be freed. The problem is ensuring the wl_data_source_dropped gets called for real after the server gets the accepted action. 2013/3/11 Giulio Camuffo <[email protected]>: > Hi all, > > I've been struggling with a problem these last few days: I'm working > on QtWayland drag and drop support, and I noticed it requires some > protocol additions, of which this is a draft: https://pastee.org/hxq26 > I want the" wl_data_source.dropped" event to be called after the > wl_data_device receives and returns from the the drop event. The > dropped event carries the action the target client chose, and i need > to be able to set the action (by calling > "wl_data_offer_accept_action") also from the "wl_data_device.drop" > event. Hence, i cannot simply post the "wl_data_source.dropped" event > just after the "wl_data_device.drop", because the > "wl_data_offer_accept_action" would be processed too late. > > I could require the client to issue a request "notify_drop", at the > end of the drop event listener, which would send the > "wl_data_source.dropped", but a client that fails to do so would be > troublesome: when a Qt client starts a drag it goes into a loop, which > is exited only when the data is dropped. If the target client didn't > send the "notify_drop" the source client would never exit from the > loop, making it stuck. > A timer could free it after some time, but that is not a good solution. > > What i need is a way to have a server-side callback when a certain > client-side event listener returns, all inside libwayland-client, > without the need for the client app to do anything. Is it possible? > I'm willing to implement it, but I don't know wayland's internals and > i'd need some pointing at. > > Thanks, > Giulio _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
