Re: X11 clipboard bug or GtkEditable bug?

[Owen Taylor <otaylor redhat com>]

Mikael Hermansson <mikeh@bahnhof.se> writes:

> Hello!
>  
> I have a Question:
> 
> I have written a new text widget for gtk (gtkextext)
> I am using the GtkEditable as baseclass and using its clipboard.
>  
> No I have seen that the GtkEditable clipboard don't like 
> windows text because Windows have '\r' and '\n' as linebreaks.
> As we already knows Linux/Unix only using '\n' as linebreak. 
> 
> This means before you try to Cut to the GtkEditable clipboard you must
> remove '\r' character before cut. 
>  
> Is this because X11 clipboard don't understand its a Text 
> because of the '\r'(0xA) character or is it a GtkEditable bug?

>From http://bugs.gnome.org/db/17/1704.html

=================
The problem here is that \r is not a legitimate character
to be transferred by the X selections; the only
control characters allowed are \n and \t.

When transferring non-internationalized text via the
STRING, you can get away with it; however, GTK+
will transfer via COMPOUND_TEXT when communicating
with itself, and thereby goes through the X conversion
routines, which refuse to accept strings with
invalid control characters. [ though they happily
generate them when converting the other way ]

There are a couple of possible solutions:

 1) Strip out control characters before converting to 
    compound text.

 2) For strings that are only ASCII + C0, transfer
    by default as STRING instead of COMPOUND_TEXT
    and include the C0 characters verbatim, even
    though they are (strictly speaking) also [not] allowed
    for STRING.

I'll put in at least 2). The problem with 1) is that 
some multi-byte encodings might include control
characters.

This will all work better in future versions of GTK+
when we move to using Unicode.

Regards,
                                        Owen
==================

I haven't actually implemented either of the above
yet, but that should give you an idea about the
problem and possible solutions. Another possibility
would be to always convert \r\n and \r alone
to \n when inserting text into an editable widget,
though that might be considered tampering with
the users data. (And would presumably not meet with
approval for the Win32 port...)

Regards,
                                  Owen