Bug 446912 - tk not allowed input nonlatin1 text
tk not allowed input nonlatin1 text
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: tk (Show other bugs)
9
All Linux
low Severity low
: ---
: ---
Assigned To: Marcela Mašláňová
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-05-16 12:31 EDT by Alexey Lubimov
Modified: 2008-06-11 02:29 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-06-11 02:29:42 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Right ~/.i18n config for users, that uses russian locale (68 bytes, application/octet-stream)
2008-05-16 12:31 EDT, Alexey Lubimov
no flags Details

  None (edit)
Description Alexey Lubimov 2008-05-16 12:31:02 EDT
Description of problem:

User with non-default locale can't type any non latin1 symbols in all tk
applications, such tkbiff or tkabber.    


Version-Release number of selected component (if applicable):

tk-8.5.1

How reproducible:


Steps to Reproduce:
1. exec LC_ALL=ru_RU.utf8
2. try to input any nonlatin1 text (Russian Cyrillic text, for example)
  
Actual results:

nothing

Expected results:

Russian Cyrillic text ;)

Additional info:

Another toolkits, such gtk or qt will work with locale ru_RU.utf8.

With default locale en_US.UTF-8 or locale ru_RU.UTF-8 tk work fine.

Workaround - create file ~/.i18n
Comment 1 Alexey Lubimov 2008-05-16 12:31:02 EDT
Created attachment 305707 [details]
Right ~/.i18n config for users, that uses russian locale
Comment 2 Alexey Lubimov 2008-05-16 12:35:58 EDT
Steps to Reproduce:

1. exec LC_ALL=ru_RU.utf8 tkdiff

2. try to input any nonlatin1 text (Russian Cyrillic text, for example)
  
Comment 3 Alexey Lubimov 2008-05-16 13:15:21 EDT
Another steps to reproduce

1)

LC_ALL=ru_RU.utf8 wish
% encoding system
utf-8
% pack [text .t] -fill both

2) try to type no latin text in text widget (not in console!)

Comment 4 Marcela Mašláňová 2008-05-19 08:23:16 EDT
I have the same problem with Czech fonts (also not in latin-1). I try to update
on tcl&tk-8.5.2 and then check it again.
Comment 5 Marcela Mašláňová 2008-05-19 09:13:00 EDT
Ok, it's not working with 8.5.2, here is upstream ticket
http://sourceforge.net/tracker/index.php?func=detail&aid=1967075&group_id=12997&atid=112997
Comment 6 Alexey Lubimov 2008-05-19 11:10:05 EDT
>Workaround:
>create file ~/.i18n with your locales. Does it mean that wish isn't looking
>for locales into shell settings?

It is not correct information.



LC_ALL=ru_RU.utf8 <TK-Program> 

is not work.

but

LC_ALL=ru_RU.UTF-8 <TK-Program> 

work fine


Diffrence in this cases - "UTF-8" or "utf8" charset.

As you can see, tcl works fine in both case:

LC_ALL=ru_RU.utf8 wish
% encoding system
utf-8


LC_ALL=ru_RU.UTF-8 wish
% encoding system
utf-8

But in TK widgets only utf8 charset not work for input text!
Comment 7 Marcela Mašláňová 2008-06-11 02:29:42 EDT
Upstream says nothing will be fixed. It has to be used "ru_RU.UTF-8". Upstream
comment:

@flatworm -- re "Gtk and Qt are immune to this problem" --

Tk uses the low-level XIM facilities built in to libX11.  Gtk and Qt both
have their own, independent, toolkit-specific, plugin-based IM
infrastructures.  So Gtk (resp Qt) processes keyboard input via a
completely different mechanism than Tk does. 

(If you set GTK_IM_MODULE=xim resp QT_IM_MODULE=xim, you should see the
same symptoms with Gtk resp Qt apps as you do with Tk apps.  Otherwise, Gtk
resp Qt will use whatever IM module is the default for your
platform/distro/locale/environment/time of day/phase of moon.)

Anyway, given this:

| ./a.out: locale=ru_RU.utf8
| ./a.out: codeset=UTF-8
| ./a.out: WARNING: X does not support locale ru_RU.utf8
|          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

and this:

| ./a.out: locale=ru_RU.UTF-8
| ./a.out: codeset=UTF-8
| ./a.out: XSupportsLocale => True


it looks like the solution is to use "ru_RU.UTF-8" as the locale, not
"ru_RU.utf8".

Note You need to log in before you can comment on or make changes to this bug.