Bug#268385: gedit: Ignores locale settings when pasting non unicode text from clipboard

[Loïc Minier]

        Hi,

 I've read your contribution (below) on Debian bug
 <http://bugs.debian.org/268385>, and I hope I won't you have some time
 to answer my doubts:

Thomas Dickey <dickey@radix.net> - Fri, Aug 27, 2004:

> > Gedit completly ignores system locale for non unicode text (xterm sel=
lection
> > for example) pasted from clipboard.  It is allays treated as iso-8895=
-1.
> The selection is in ISO-8859-1 anyway simply because that's the standar=
d
> behavior (for X).

 I'm kind of a beginner with Xlib and such stuff, so I naively tried to
 find some documentation on this, and so far I've reached these
 preliminary conclusions while reading the Xlib Programming Manual:
 - X clients can exchange Selection Atoms via the PRIMARY and
   SECONDARY selection atoms,
 - the exchange is requested via a call to XConvertSelection(), which
   might specify a target type as an Atom parameter to the call,
 - the actual exchange is done via a SelectionNotify event from the
   owner or the X server to the requestor,
 - the data of the exchange is carried by a property name, such as
   "CUT_BUFFER0", and its property type such as "STRING".

 What I did not understand, is how the "property name" is choosen, and
 where the definition of a STRING is: I presume this is the place where
 ISO-8859-1 is agreed upon.

 Do you think it would be possible to change Gtk in a way that it
 requests a new type of data -- such as "STRING-UTF-8" or in a more
 clever way (such as with a charset parameter) -- falling back to a
 "STRING" request when "STRING-UTF-8" isn't available?  Or is it simply
 impossible to support non-ISO-8859-1 text selections without
 reinventing yet another X protocol?

   Thanks,

-- 
Loïc Minier <lool@dooz.org>