server side callback

[Jason Ekstrand]

Guilio,
The big problem here is that, unlike the server, events client-side
are handled in multiple event loops.  Server-side, everything is
handled in a single event loop and events (at least on a per-client
basis) are handled in order (I think this is even in the spec).  On
the client-side, where the event is handled depends on the object and
the events may be handled in different threads.  For this reason, you
can't just have a "sync" event because it may get handled in some
other thread and actually be handled before an event that gets sent
earlier.

What might be possible, however, is to have a sync_next_event event
(probably in wl_display).  This event would get detected in libwayland
and "attached" to the subsequent event so that the server can get
notified.  That said, there are a number of reasons why this may be a
bad idea:

1. It breaks the asynchronous nature of libwayland.  Much of the
wayland protocol is designed to avoid round-trips between client and
server and this would add round trips.

2. Clients may not handle it correctly.  For instance, what if all the
event handler did was to fire a signal inside the toolkit.  That
signal might get executed right away or it may simply get queued for
later execution on another thread.  If this happens, the server will
get notified before the event actually does anything.

3. You have to deal with the the timeout case anyway.  The client may
hang or crash in any event and the sync may never get sent.

4. This has the potential, if not used carefully, to lead to a lot of
race conditions.  What happens if, inside of the synced event, the
client does something and then calls wl_display_roundtrip?  While I
think this could probably be handled correctly in most cases, it makes
for a mess.

I'd love to offer some thoughts on the more general drag-and-drop
problem if you want to give a more detailed description.
Specifically, I read some of the conversation on IRC today, but I'm
not sure I understand why the dropped event is needed.  That said, I
may not be the best one to help you as I don't know the wayland D&D
system that well, I'd mostly just be helping brainstorm.

On Mon, Mar 11, 2013 at 4:53 PM, Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
> 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
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel