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 <[EMAIL PROTECTED]> - Fri, Aug 27, 2004: > > Gedit completly ignores system locale for non unicode text (xterm sellection > > 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 standard > 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 <[EMAIL PROTECTED]>
