When I'm trying to copy russian text from some applications to NEdit, I get '?' characters instead, while copying any characters with ASCII < 128 works just fine. When I'm trying to copy russian text in other direction (i.e. from NEdit to these applications) then I get some unreadable characters as if I was trying to read text with wrong locale settings (iso8859-5 instead of microsoft-CP1251).
This problem applies to applications that using QT3, such as Kate from KDE3, Opera 6.12, LICQ 1.2.6. When I used Kate from KDE2 there was no such problem with it, so maybe QT3 is the key? Anyways, there is no such problem with all GTK+ applications (xmms and stuphead), and copying from, for example, from Opera to stuphead and then from stuphead to NEdit works just fine. Copying back through the same chain too.
I am using NEdit 5.3 compiled with lesstif 0.93.34-2mdk from MandrakeLinux 9.0 distribution.
The same problem also was with lesstif 0.92.32-6 from RedHat 7.2 distribution.
Logged In: YES
user_id=767904
After spending long time digging in X, QT, lesstif and NEdit sources I
realized that it is really QT3 bug, not NEdit. QT3 just forces
selection/clipboard text to be interpreted as ISO-8859-1 regardless of
any locale settings.
I wonder why this bug affected only copying to NEdit, but fixing this
(just doing "global replace" string "text/plain;charset=ISO-8859-1" to
"text/plain" on file kernel/qclipboard_x11.cpp in QT3 sources) solved
the entire problem, so it doesn't matter much anymore...
Logged In: YES
user_id=11321
This may be a nedit bug. Looking at the X docs, it say that
a STRING propery is assumed to be ISO Latin-1, which
implies QT is right. Nedit probably needs to support
internationlized apps by informing X that the text in the
clipboard is whatever the current locale is.
Logged In: YES
user_id=767904
>This may be a nedit bug. Looking at the X docs, it say that
> a STRING propery is assumed to be ISO Latin-1, which
>implies QT is right.
So, it means that copying text with XtGetSelectionValue() is just wrong
for all non-latin1 encodings?! I am saying this because value returned
by that function *already* with question marks (I've checked this with
good old printf), so NEdit obviously can't do anything with it.
>Nedit probably needs to support
>internationlized apps by informing X that the text in the
>clipboard is whatever the current locale is.
See above.
NEdit can do anything it wants, but QT just *forces* content to be
ISO-8859-1, while it may (as it were in QT 2.x) just specify content as
"text/plain" and let X and any other apps interpret content as whatever
they like - it is never too late to imply ISO-8859-1 encoding.
Anyways, I've already posted this to qt-bugs@trolltech.com :-) so I
hope somebody there or here will do something about it. Maybe solution
that I made is inaccurate - well, then let developers find clean and right
solution :)
Logged In: YES
user_id=11321
For copying out of nedit...
When we put something on the clipboard, we have to tell X
what it's data type is. From my reading, if we put type
"STRING" on the clipboard, that means Latin-1. The rub is
you may have started NEdit up in a non Latin-1 locale, and
are looking at something very different.
I _think_ the solution is to put the text on the clipboard
as COMPOUND_TEXT which says - "this text has the encoding"
and specify the locale you started up with iso8859-5.
If Qt ignores the specified encoding of COMPOUND_TEXT, then
it is a Qt bug. But since NEdit has had no i18n work done
it, and Qt has, I expect Qt to be correct here...
For copying into nedit, I'm not sure.. I think we need to
request a COMPOUND_STRING of the current locale.
Logged In: YES
user_id=767904
>From my reading, if we put type
>"STRING" on the clipboard, that means Latin-1.
Hmm... Now I understand (at least I think so ;-))...
Well, but the main problem was copying INTO nedit. Copying out
sometimes could be fixed with some crazy manipulations with locale
settings (don't remember exactly what), but copying INTO nedit
*always* ends up with quotation marks :-( regardless of any locale
settings or something else.
But it seems that you're right in both cases - it doesn't seem to be QT3
bug at all (although easiest way to fix it is to edit QT3 sources and
recompile it). I've been mislead by that fact that copying from any QT2
and non-QT apps (GTK+ and others) into the SAME nedit version worked
just fine! Only QT3/nedit pair gave me that damn question marks.