Re: [PATCH] Implement paste from clipboard functionality

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

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.

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 Novotny<minovotn redhat com>, RHCE
Virtualization Team (xen userspace), Red Hat

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