Bug 752350

Same thing with Fedora 16 client and Windows XP guest.

BTW this feature (auto translation) is present in vmware server, vmware workstation etc and its transparent (no option to disable/enable it).

This request was not resolved in time for the current release.
Red Hat invites you to ask your support representative to
propose this request, if still desired, for consideration in
the next release of Red Hat Enterprise Linux.

This request was erroneously removed from consideration in Red Hat Enterprise Linux 6.4, which is currently under development.  This request will be evaluated for inclusion in Red Hat Enterprise Linux 6.4.

Moving to spice-gtk since the bug is reproducible over there and spice-client is being dropped.

out of time for 6.4.

I'll be writing a patch for this, so assigning this to me, until said patch is upstream.

Patch posted upstream, moving to post:
http://lists.freedesktop.org/archives/spice-devel/2013-June/013736.html

Patch is upstream now, re-assigning to spice-gtk RHEL maintainer, please add to the next build.

Note to QA, testing this requires using a Linux agent with bug 799482 fixed, or a Windows agent with bug 872252 fixed.

This is now built, Hans can you check the doc text is correct?

(In reply to Christophe Fergeau from comment #16)
> This is now built, Hans can you check the doc text is correct?

Doc text looks good to me, thank you for taking care of this.

(In reply to David Jaša from comment #0)
> Description of problem:
> When copying plain text from gnome-terminal in RHEL guest to notepad in
> Windows client, notepad displays all the content on single line. 

Not true with gtk+ client. Gtk+ already does to and from conversion, so Windows client to Linux guest c&p just works already.

However the problematic combination is Windows->Windows or Linux->Windows, since gtk+ convert to utf8 LF. I am quite sure Hans patch only solved Linux->Windows. Hans have you tried with windows client?

Since that bug is about RHEL client, we can leave it as is, or we can remove it from QA until there is a better solution upstream.

I am working on patches to fix this.

(In reply to Marc-Andre Lureau from comment #20)
> (In reply to David Jaša from comment #0)
> > Description of problem:
> > When copying plain text from gnome-terminal in RHEL guest to notepad in
> > Windows client, notepad displays all the content on single line. 
> 
> Not true with gtk+ client. Gtk+ already does to and from conversion, so
> Windows client to Linux guest c&p just works already.
> 
> However the problematic combination is Windows->Windows or Linux->Windows,
> since gtk+ convert to utf8 LF.

??? There is no such thing as UTF-8 LF, UTF-8 is capable of encoding both CR and LF. Do you mean under win 32 gtk does automatic line-ending conversion (which is an orthogonal problem from character encoding) ?

> I am quite sure Hans patch only solved
> Linux->Windows. Hans have you tried with windows client?

No, but I did try conversion in both directions by putting CRLF ending text in the clipboard under Linux
and having the Linux client think it was a windows client from a line-ending pov. To be precise for this test I hardcoded CLIENT_LINEEND_LF to 0 and CLIENT_LINEEND_CRLF to 1. With this hack + injecting CRLF terminated text into the X-windows clipboard on the client I tested copy paste from a "Windows" client to a Linux guest and the CRLF line-endings where correctly converted into Unix style LF line-endings.

IOW unless gtk-win32 does some sort of line-ending conversion itself under the hood (and I cannot really think of good reasons for it to do that), when you build the windows client using new enough spice-gtk code this should all just work.

(In reply to Hans de Goede from comment #21)
> (In reply to Marc-Andre Lureau from comment #20)
> > (In reply to David Jaša from comment #0)
> > > Description of problem:
> > > When copying plain text from gnome-terminal in RHEL guest to notepad in
> > > Windows client, notepad displays all the content on single line. 
> > 
> > Not true with gtk+ client. Gtk+ already does to and from conversion, so
> > Windows client to Linux guest c&p just works already.
> > 
> > However the problematic combination is Windows->Windows or Linux->Windows,
> > since gtk+ convert to utf8 LF.
> 
> ??? There is no such thing as UTF-8 LF, UTF-8 is capable of encoding both CR
> and LF. Do you mean under win 32 gtk does automatic line-ending conversion
> (which is an orthogonal problem from character encoding) ?

I know, I mean gtk+ uses UTF-8 LF internally.

See also this bug I opened for more details:
https://bugzilla.gnome.org/show_bug.cgi?id=706657

> > I am quite sure Hans patch only solved
> > Linux->Windows. Hans have you tried with windows client?
> 
> No, but I did try conversion in both directions by putting CRLF ending text
> in the clipboard under Linux

That's not good enough. It just doesn't work with Windows client. I am sending patches to the ML this evening.

new patch series:
http://lists.freedesktop.org/archives/spice-devel/2013-August/014219.html

(In reply to Marc-Andre Lureau from comment #22)

<snip> 

> I know, I mean gtk+ uses UTF-8 LF internally.
> 
> See also this bug I opened for more details:
> https://bugzilla.gnome.org/show_bug.cgi?id=706657

Ugh. having gtk strip all the CR-s is bad. This means we need to re-insert the CR-s when doing windows <-> windows copy - paste. And this also means that if in windows we've text with just LF-s in the clipboard and we copy it to/from windows we and up inserting CR-s, thus modifying the text.

Anyways, I realize there is nothing we can do here as long as gtk is not fixed, thanks for filing the gtk bug.

I agree that adding back the CR-s when doing windows <-> windows copy paste is the best we can do for now, so I'll go and review your patch-set for this.

<snip>

Regards,

Hans

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1577.html

Robert, 

Are you running >= vdagent-win-3.3-1 in the Windows guest?

Can you provide SPICE_DEBUG=1 remote-viewer log?

thanks