Re: Multi-lingual cut & paste support (was Re: One for our asian language experts...)

[Kazunobu Kuriyama]

Hi, Fred and all,

Fred Kiefer wrote:

> Kazunobu Kuriyama wrote:
>
> > Attached is the patch that enables multi-lingual cut & paste with gpbs.
>
>
> This patch is rather nice and improves behavior in many cases. But it 
> also makes it worse in the interaction with an old X application that 
> only supports STRING or COMPOUND_TEXT. What we should do in the long 
> run is to ask for all different types we are able to support for text 
> and also provide all the different types ourself. Than the best 
> matching type could be used.

I don't think at all it makes worse because even the older versions of 
gpbs have not
supported COMPOUND_TEXT; I'm afraid you cannot compare the modified gpbs 
with the
older ones in terms of it.  Nonetheless, I think you are suggesting a 
good point
we should discuss.

I think the suggested way is just part of the discipline which X11-based 
libraries
should keep. Nonetheless, I'd like you and all folks to listen to my 
reasons again,
although they are similar to those in the email you quote. You might 
find that the
implication of your suggestion is much more than you had expected. The 
implication
is likely to drive us (me, at least) to a more complicated situation (or 
the hell).
Therefore, I'd like to make up my mind whether or not I modify the code 
further
after receiving your reply on mine to this issue.

As I mentioned in the email you quote, the new implementation is 
exploited only if
the underlying window system is XFree86 4.0.2 or higher. Otherwise, the 
implementation
falls back to the original one.  So one of the cases we should take into 
consideration
is this: the Copy & Paste interaction between the current GNUstep and X 
toolkits/clients
which were developed under the older X11's, i.e., those not using the 
X11's utf8 extension
(directly or indirectly through the relevent libraries to which they are 
linked).

As a user of such an old X11 toolkit/client, there may be two choices:
(1) Ask GNUstep to correct the gpbs's behavior.
(2) Ask the X11 toolkit's or client's developer to update its code so 
that it can
   make use of the utf8 extension.
I think the latter is much better because it is likely to bring "genuine 
progress"
not only to our community but also to the outside of the GNUstep world. 
Technically,
making use of the API is much easier than creating a new, complicated 
version of
gpbs.

In the same mail, I also talked about a possible problem caused by the 
locale an
application uses (under the condition that unicode is not used).  
Because there
are various possible cases in which GNUstep applications interact with 
non-GNUstep ones,
I don't think we can specify a unique GNUstep's behavior which makes all 
users
satisfy with it.  More specifically, suppose you have Ink running under 
LANG=de_DE,
and xedit under LANG=ru_SU (SU is still used?), and 
GNUSTEP_STRING_ENCODING is set to
NSJapaneseEUCStringEncoding.  Now you are trying to do copy and paste 
between the
Ink and the xedit of which contents has Russian words with their 
Japanese translation.
Then can we specify "the right behavior" which GNUstep should have?  In 
other words,
can we uniquely specify the encoding the user wants to use primarily?  
Off course, we
could impose it on every user; however, I'm afraid some people won't be 
satisfied with
it and someday we'll have an email entitled "gpbs is broken..."

I suspect, therefore, we cannot offer any "silver bullet" against the 
problem above in
a manner which makes everybody happy even if we make some effort by 
which GNUstep
supports COMPOUND_TEXT.  After all, the problem is rooted in the locale 
mechanisms
of both unices (the standard C library) and X11, plus the mess lying 
between them; if
there were no problem over there, the X11 people would never devise the 
utf8 extension.

Taking all above into consideration, I made the patch and explained in 
the email why
I didn't write code in such a way that it supports COMPOUND_TEXT.

IMHO, the X11's utf8 extension really makes our lives much easier. :-)  
Also, I guess
COMPOUND TEXT will be gone away in relatively near future because 
genuine i18n
applications are hardly written with it.

Cheers,
- Kazu

P.S.
Having said so, if you have other reasons stronger than mine, or if 
there's someone who
really gets into trouble with the recent extension to gpbs, feel free to 
let me know
via the mailing list.  I'll see to it as possible as I can.  Otherwise, 
I'll humbly reply
to you, "Update your X and recompile GNUstep with it.  Ask the X 
toolkit's or client's
developer to update the code to support utf8.  To be sure, it sounds 
annoying; however,
in the long run, you will get much benefit from it, which can be shared 
with people in
the open source community. (At least, it saves my time anyway! :-)"