server side callback

[Giulio Camuffo]

2013/3/12 Pekka Paalanen <ppaalanen at gmail.com>:
> On Tue, 12 Mar 2013 11:22:00 +0100
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>
>> 2013/3/12 Jason Ekstrand <jason at jlekstrand.net>:
>> >
>> > 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.
>>
>> When starting a drag, the source Qt app goes into a loop. It can still
>> redraw itself and get the events, but it is waiting for the dnd to
>> finish before going on with what it was doing. So i need a
>> notification, when the target has got the drop, which lets the source
>> client exit the loop and go on. If the source doesn't get this
>> notification it won't exit the loop and will be stuck. Besides, the
>> source needs it also to be able to free its wl_data_source.
>
> A stupid question: why can't the source application simply close the
> pipe, destroy the wl_data_source, and continue after it has written all
> the data into the pipe? It already has to poll the pipe for writable,
> so I think it should be able to detect also things like the receiver
> aborting by closing the pipe fd. And receiver would poll and continue
> reading until it gets EOF. Would it work like that?
>
> Could closing one end of the pipe be gracefully detected on the other
> side, so one would not have to have more Wayland protocol?

That would be a good way to handle crashing apps, but I don't think
exiting the loop after sending the data is a good solution. I think
the target client should be allowed to get the data before the drop
happens, caching it, or even more that one time. It may need to check
what's in the data and change its ui accordingly, for example.

>
>
> Thanks,
> pq
>
>> > 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.