Re: [PATCH] Implement paste from clipboard functionality



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
-- 
|: http://berrange.com      -o-    http://www.flickr.com/photos/dberrange/ :|
|: http://libvirt.org              -o-             http://virt-manager.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: http://entangle-photo.org       -o-       http://live.gnome.org/gtk-vnc :|


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]