Mailing List ArchiveSupport open source code!
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: XIM, kinput2 & Tk
- To: jwb@example.com (Jim Breen)
- Subject: Re: XIM, kinput2 & Tk
- From: "Stephen J. Turnbull" <turnbull@example.com>
- Date: Tue, 15 May 2001 20:21:18 +0900
- Cc: tlug@example.com
- Content-Transfer-Encoding: 8bit
- Content-Type: text/plain; charset=iso-8859-1
- In-Reply-To: <200105151007.TAA29837@example.com>
- References: <200105151007.TAA29837@example.com>
- Reply-To: tlug@example.com
- Resent-From: tlug@example.com
- Resent-Message-ID: <3RwK4C.A.P6G.tERA7@example.com>
- Resent-Sender: tlug-request@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. 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."
- References:
- Re: XIM, kinput2 & Tk
- From: jwb@example.com (Jim Breen)
Home | Main Index | Thread Index
- Prev by Date: Re: XIM, kinput2 & Tk
- Next by Date: Re: Linux with Windows2000
- Prev by thread: Re: XIM, kinput2 & Tk
- Next by thread: Re: XIM, kinput2 & Tk
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links