Hi all, I realized few questions about drag'n'drop that I maybe missed in previous threads:
1) why id d'n'd designed for file only, and spice-vdagent is the component in the receiving system that would do the hard work? Or alternatively phrased: Could vdagent register itself in the guest system as d'n'd application and pass the data as in-guest d'n'd event to the guest app that would receive the drop event? If I understand d'n'd correctly, approach like this would leave dealing with issues like lack of space on receiving volume to the app that will eventually receive the drop event and it would also allow stuff like drop of the file right to application that could open the received file right away (drag .doc file from nautilus in the client and drop it on MSO window in the Windows guest for example). The downside could be that the receiving app might freeze for the time of actual data transfer if it receives data synchronously 2) possible path for guest -> client transfers (mainly @Hans and @Arnon): this is a kind of extension of the question/idea above: would it be possible somehow for vdagents to have some invisible drop-receiving area where the guest mouse pointer could be moved when mouse leaves the client window? Client could then behave as drag source in the client system and again drop the data right to the receiving application 3) possible OS interoperability issues in such "dumb"/"transparent" mode approach outlined in 1) and 2) quite heavily relies on data being from sending system will be usable by receiving system. Are d'n'd implementations in Windows and X ecosystems similar enough to allow such approach? 4) speculative transfer would it be possible to initiate network transfer right when user _starts dragging_ and keep it cached on receiving side till drop event? Behaviour like this could tremendously improve ux for moderately large files and less-then-LAN bandwidth (copy/paste would benefit from this as well). David Dunrong Huang píše v St 28. 11. 2012 v 19:55 +0800: > At present, Vmware and Virtualbox has supported file drag&drop feature, > I think it's a good feature for users, so we want qemu/spice to > supports it. > > This patch first adds communication protocol between client and guest, > we must make the agent protocol stable before coding, this is what we > want this patch to do. > > This feature has been discussed on spice mailing list. > > The more details are available at following pages: > http://lists.freedesktop.org/archives/spice-devel/2012-November/011400.html > and > http://lists.freedesktop.org/archives/spice-devel/2012-November/011485.html > > Signed-off-by: Dunrong Huang <riegama...@gmail.com> > Cc: Hans de Goede <hdego...@redhat.com> > Cc: Marc-André Lureau <marcandre.lur...@redhat.com> > Cc: Alon Levy <al...@redhat.com> > Cc: Uri Lublin <u...@redhat.com> > --- > V2 -> V3: > * Use key-value text as data included in start message > * s/VD_AGENT_FILE_XFER_RESULT_/VD_AGENT_FILE_XFER_STATUS_/ > > s/VD_AGENT_FILE_XFER_RESULT_SUCCESS/VD_AGENT_FILE_XFER_STATUS_CAN_SEND_DATA/ > * Drop data compression > > V1 -> V2: > Address Hans's comment > spice/vd_agent.h | 25 +++++++++++++++++++++++++ > 1 file changed, 25 insertions(+) > > diff --git a/spice/vd_agent.h b/spice/vd_agent.h > index 2b9884e..b05da3e 100644 > --- a/spice/vd_agent.h > +++ b/spice/vd_agent.h > @@ -69,9 +69,34 @@ enum { > VD_AGENT_CLIPBOARD_GRAB, > VD_AGENT_CLIPBOARD_REQUEST, > VD_AGENT_CLIPBOARD_RELEASE, > + VD_AGENT_FILE_XFER_START, > + VD_AGENT_FILE_XFER_STATUS, > + VD_AGENT_FILE_XFER_DATA, > VD_AGENT_END_MESSAGE, > }; > > +enum { > + VD_AGENT_FILE_XFER_STATUS_CAN_SEND_DATA, > + VD_AGENT_FILE_XFER_STATUS_CANCELLED, > + VD_AGENT_FILE_XFER_STATUS_ERROR, > +}; > + > +typedef struct SPICE_ATTR_PACKED VDAgentFileXferStatusMessage { > + uint32_t id; > + uint32_t result; > +} VDAgentFileXferStatusMessage; > + > +typedef struct SPICE_ATTR_PACKED VDAgentFileXferStartMessage { > + uint32_t id; > + uint8_t data[0]; > +} VDAgentFileXferStartMessage; > + > +typedef struct SPICE_ATTR_PACKED VDAgentFileXferDataMessage { > + uint32_t id; > + uint64_t size; > + uint8_t data[0]; > +} VDAgentFileXferDataMessage; > + > typedef struct SPICE_ATTR_PACKED VDAgentMonConfig { > uint32_t height; > uint32_t width; -- David Jaša, RHCE SPICE QE based in Brno GPG Key: 22C33E24 Fingerprint: 513A 060B D1B4 2A72 7F0D 0278 B125 CD00 22C3 3E24 _______________________________________________ Spice-devel mailing list Spice-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/spice-devel
