Re: [PATCH] Implement paste from clipboard functionality

[Michal Novotny <minovotn redhat com>]

On 12/16/2010 09:27 PM, Daniel P. Berrange wrote:
> On Thu, Dec 16, 2010 at 08:06:03PM +0000, John Haxby wrote:
> > On 16 Dec 2010, at 19:47, Daniel P. Berrange wrote:
> >
> > > On Wed, Dec 15, 2010 at 07:06:24PM +0100, Michal Novotny wrote:
> > > > Hi,
> > > > this is the patch to implement paste from clipboard to the VNC Window
> > > > functionality. This is the first version of the patch, tested mainly
> > > > to copy&  paste URL addresses to the virtual machines to be used as
> > > > an installation source (e.g. in anaconda when using network install).
> > > > The core functionality is done by the vnc_display_clipboard_paste()
> > > > functionality that has been inspired by xsel source code to grab the
> > > > clipboard contents. Also, a new function to send multiple scancodes
> > > > per character, called the vnc_display_send_character() has been
> > > > introduced since vnc_display_send_keys_ex() was having issue when
> > > > sending multiple characters at once. Mainly special characters like
> > > > slashes, backslashes, commas, semicolons, exclamation marks etc.
> > > > were having issues when used in vnc_display_send_keys_ex() so the
> > > > implementation of vnc_display_send_character() was necessary for
> > > > this purpose.
> > > IMHO this is really not a desirable approach to the problem
> > > of cut+paste. VNC has a proper cut+paste protocol. The issue
> > > is that with virtual machines, there's no automatic way to
> > > wire this up to the guest OS. It requires an agent to be
> > > installed in the guest OS, at which point QEMU can wire up
> > > the normal VNC cut+paste support. A VNC client has no way to
> > > know whether cut+paste is supported or not, so it can't tell
> > > whether to use the regular VNC cut+paste APIs, or this alternative
> > > approach you're proposing. If an agent is not present, then QEMU
> > > itself coould fake the 'paste' operation using the approach you
> > > demonstrate of generating key events.
> >
> > The send scan-code approach doesn't work in a variety of contexts
> > as well.   The obvious one is that while I can't type (say) any
> > Indic scripts I can certainly copy them from a web page and paste
> > them somewhere else, but I wouldn't even begin to know what keys
> > to press to get the same characters.   Even if you limit yourself
> > to glyphs that (more-or-less) appear on the keyboard you can run
> > into trouble when the VNC server's idea of (say) "@" is a shift-2
> > it's actually shift-something-on-the-right when the client has a
> > different keyboard: you get this kind of problem with all kinds of
> > vnc server.
> Yes that's a good point I'd forgotton. We avoid that problem with
> QEMU thanks to the scancode extension. We don't want to reintroduce
> the problem in another area.
>
> > > So in summary I don't think this patch belongs in GTK-VNC. You
> > > might propose this as an idea on qemu-devel, and see if they think
> > > it is desirable for QEMU itself todo this in the non-guest agent
> > > scenario.
> >
> > It might be worth proposing, but I think it was suggested a while
> > ago and decided against.  Because it's not a "paste" but "convert
> > a selection into a collection of keystrokes" it's prone to all
> > kinds of problems, not only the difficulty of translation to scan
> > codes in everything but ASCII (and possibly even a only on a US
> > keyboard).   Another fairly serious problem is that if you paste
> > a few kilobytes of data then you're pushing the keyboard input
> > stack incredibly hard.  These interfaces are designed for human
> > typing speeds and even a few kilobytes will drive Thunderbird
> > (say) to distraction.   Tens of kilobytes will probably lock you
> > out for longer than you're prepared to wait.
> Based on these two points, I wouldn't even bother proposing it to
> qemu-devel. I'd vote against it myself.
>
> Regards,
> Daniel
Thanks for your feedback guys. The approach was tested mainly to copy & 
paste URL address when doing many VMs network install and for this 
scenario it was working fine. Truth is that no other scenarios were 
tested nor meant to be used with since this was just alpha version of 
the patch. If we decide to vote against this patch I have learned how to 
grab X-Window clipboard/selection in my spare time which is certainly a 
good thing to know at least. I wrote it for my own purposes of 
installing VMs as based on collegue's suggestion since he was asking me 
whether Virt-Manager supports it or not. I think there should be a list 
of features that were voted not to implement with their reasons why.

Thanks for your feedback once again,
Michal

--
Michal Novotny<minovotn redhat com>, RHCE
Virtualization Team (xen userspace), Red Hat