server side callback

[Pekka Paalanen]

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.


Thanks,
pq