2013/3/12 Pekka Paalanen <[email protected]>: > On Tue, 12 Mar 2013 12:00:57 +0100 > Giulio Camuffo <[email protected]> wrote: > >> 2013/3/12 Pekka Paalanen <[email protected]>: >> > On Tue, 12 Mar 2013 11:22:00 +0100 >> > Giulio Camuffo <[email protected]> wrote: >> > >> >> 2013/3/12 Jason Ekstrand <[email protected]>: >> >> > >> >> > 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 _______________________________________________ wayland-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/wayland-devel
