Mailing List Archive

Support open source code!


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: XIM, kinput2 & Tk



>>>>> "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.

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.

It would be nice if it were otherwise, but it's not.  IMO YMMV etc.

    Jim> I don't say [POSIX] is responsible [for all breakage], but I
    Jim> do say that it appears clumsy and inadequate.

Well, yeah.  But nobody knows how to do it any better because nobody
knows how to POSIX in practice.  You walk before you run.  Let's get
POSIX right, first, or some close approximation.

This is a bad time for you because people (eg, the Tcl crowd) are
trying to get it right for once.  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.  (I'm talking about programmers,
not Japanese, BTW -- gotcha!)  As Lao Tse said, "So hearing of The
Way, they laugh."  And then there's Uli Drepper (the glibc kami), who
is a Way unto himself: no compromise.  (Laughter stops. :-þ )

Tough luck for you and for the "out-of-the-box" Linux wannabes.  But
the fast fixes are not very good, and are not a foundation for the
long term.  Maybe Pango and the GTK stuff will pay off; maybe Qt will
beat them to it, I dunno.

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.  :-)

    >>> char JimsLocale[A_BIG_ENOUGH_NUMBER];
    >>> char save_locale[A_BIG_ENOUGH_NUMBER];

    Jim> [snip]

    Jim> That's not going to be great for everyone wanting to wanting
    Jim> an international environment either.

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?

    >>> But that's not all that bad, changing IMs is a really rare
    >>> event.

    Jim> I know people in the Windblows world who do it all the
    Jim> time. I'll never even try to convert them to **nix if they
    Jim> have to write wrappers, set umpteen variables, etc. etc.1

*snort*  A human being cannot possibly change IMs "often."  I'm
talking about the "system calls are slow" scale of time.  You'd at
least need to be able to write a macro; that lets out the Windosed
right there.


-- 
University of Tsukuba                Tennodai 1-1-1 Tsukuba 305-8573 JAPAN
Institute of Policy and Planning Sciences       Tel/fax: +81 (298) 53-5091
_________________  _________________  _________________  _________________
What are those straight lines for?  "XEmacs rules."


Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links