server side callback

[Giulio Camuffo]

2013/3/12 Pekka Paalanen <ppaalanen at gmail.com>:
> On Tue, 12 Mar 2013 12:00:57 +0100
> Giulio Camuffo <giuliocamuffo at gmail.com> wrote:
>
>> 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.
>
> Hmm, this sounds like you are trying to extend D&D to become a generic
> client-to-client communication mechanism. Is that really necessary?
>
> I didn't really understand the use case here. Why does the source app
> need to care how or when the target app is processing the data, as
> long as all of the data is sent? I believe any further communication is
> meant to be application-specific and not involve Wayland.

I don't see why reading the data before having the drop would be a
generic client-to-client comunication. It's still drag & drop.
But yeah, i guess the source app could assume once it has sent the
data it's done, but that actually doesn't fix my problem. Given the
current Qt QPA api, i need to both be able to provide the data before
the drop happens and to exit the loop at the drop. Also, i need to be
able to set the accepted action (wl_data_offer_accept_action in the
paste of the first mail) at enter, move and drop events. The point is
that when i push the drop event into Qt i get the final accepted
action with which i must exit the loop.

I guess i'll require the client to notify the drop is finished, with
some timer to handle misbehaving apps.

>
>
> Thanks,
> pq