Re: [PATCH] Implement paste from clipboard functionality

[John Haxby <john haxby oracle com>]

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.


> 
> 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.

jch