Re: XIM, kinput2 & Tk

[jwb@example.com (Jim Breen)]

>> From: "Stephen J. Turnbull" <turnbull@example.com>
>> >>>>> "Jim" == Jim Breen <jwb@example.com> writes:
>> 
>>     Jim> You can't really tell users who want to run stuff
>>     Jim> out-of-the-box to create wrappers and set arcane variables
>>     Jim> all the time.
>> 
>> No, you tell them to go to Mama Microsoft.  That's what Microsoft is
>> for.

Now, now. Even in the *nix world that's totally heretical.

>> Look, kterm is TWENTY years old (or nearly so).  And still broken.  If
>> we can't afford to get kterm fixed, we can't afford to have everybody
>> else doing it their own way, too!   We'll never dig our way out from
>> under the compost heap.

I've simply been using kterm as an example. Ideally I'd prefer a fully
internationalized *term, and yes, I'd even be prepared to set variables,
run it in a wrapper, etc. although longer term these things *must* get
into configuration tools.

>> This is a bad time for you because people (eg, the Tcl crowd) are
>> trying to get it right for once.  

And not getting it right. For example, Tk will not automatically display
Japanese unless you have LANG set to ja_JP, will not engage kinput2/XIM
unless pactically the whole environment is Japanese.

>> You happen to be dependent on
>> software for Japanese, which (a) is historically full of kludges
>> isomorphic to the language itself, and (b) mostly is maintained by
>> people who are culturally predisposed to kaizen'ing things to death
>> rather than fixing them by design.  

Personally that is not a problem for me. I can live with it. However I
do produce software for other people to use. Mostly it is software for
non-Japanese people to do things involving Japanese text, and whereas in
the past I could say things like "run it in a kterm, and be sure to
install the fonts", that is not adequate for more sophisticated tools.
At present it seems I have to issue convoluted sets of variable settings
and wrappers, which vary according to distro, shell, phase of the moon,
etc. Worse, some of those settings are quite likely to change default
actions of other applications.

>> Tough luck for you and for the "out-of-the-box" Linux wannabes.  

Yep. Unix/Linux is only for he-man users.

>> OK, OK, I'll go take a look around, then write the book.  Some year
>> soon.  Call up Ken and tell him to lobby Tim to pay me for it.  :-)

The need is there. I know a few of Tim's authors, and I'll drop hints as
much as I can.

>> Huh?  It's a perfectly general fallback.  Wrap it in a nice libglade
>> dialog, with the common locales in a config file where they can be
>> registered by the IMs that support them.  Most people will actually
>> get their IMs chosen to match their primary locale, and never need (or
>> see, if the program is written right) the dialog.  What's the problem?

Not a problem at all if it is a config tool. A big problem if it is a
user who doesn't know a libglade dialogue from a horse's arse.

Jim
-- 
Jim Breen  [jwb@example.com  http://www.csse.monash.edu.au/~jwb/]
Visiting Professor, Institute for the Study of Languages and Cultures of 
Asia and Africa, Tokyo University of Foreign Studies, Japan
+81 3 5974 3880         [$B%8%`!&%V%j!<%s(B@$BEl5~30Bg(B]