Re: server side callback
2013/3/12 Jason Ekstrand ja...@jlekstrand.net: 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. Ok, thanks for your insight. 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 DD 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. On Mon, Mar 11, 2013 at 4:53 PM, Giulio Camuffo giuliocamu...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
On Tue, 12 Mar 2013 11:22:00 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Jason Ekstrand ja...@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 DD 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? Thanks, pq On Mon, Mar 11, 2013 at 4:53 PM, Giulio Camuffo giuliocamu...@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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
2013/3/12 Pekka Paalanen ppaala...@gmail.com: On Tue, 12 Mar 2013 11:22:00 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Jason Ekstrand ja...@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 DD 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 giuliocamu...@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. ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
On Tue, 12 Mar 2013 12:00:57 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Pekka Paalanen ppaala...@gmail.com: On Tue, 12 Mar 2013 11:22:00 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Jason Ekstrand ja...@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 DD 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 DD 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 ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
2013/3/12 Pekka Paalanen ppaala...@gmail.com: On Tue, 12 Mar 2013 12:00:57 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Pekka Paalanen ppaala...@gmail.com: On Tue, 12 Mar 2013 11:22:00 +0100 Giulio Camuffo giuliocamu...@gmail.com wrote: 2013/3/12 Jason Ekstrand ja...@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 DD 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 DD 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 wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
Given it seems to me it's not clear how the additions in the spec would work i'll write an example here: we have two apps, S (source) and T (target). S creates the wl_data_source, calls wl_data_source_offer with the supported mime types and calls wl_data_source_set_actions with one or more supported actions, using bitwise OR. T gets the wl_data_offer, the wl_data_offer_offer events and the wl_data_offer_actions with the actions set by wl_data_source_set_actions. T gets the drop event. T asks for the data and calls wl_data_offer_accept_action with one of the supported actions, or the ignore action. After this, after the server gets the accepted action, the wl_data_source would need to be notified, by wl_data_source_dropped, which carries the accepted action with it. In QtWayland i can now exit the loop and give the accepted action to Qt. But before doing that T calls wl_data_offer_finish which calls wl_data_source_cancel on S's wl_data_source so it can be freed. The problem is ensuring the wl_data_source_dropped gets called for real after the server gets the accepted action. 2013/3/11 Giulio Camuffo giuliocamu...@gmail.com: 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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
Re: server side callback
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 DD system that well, I'd mostly just be helping brainstorm. On Mon, Mar 11, 2013 at 4:53 PM, Giulio Camuffo giuliocamu...@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@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel ___ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
