KHIM

Kevin Kenny 2006-08-27 (from c.l.t. ANNOUNCE: KHIM 1.0 added to tklib) - I finally managed to get around to bundling up a releasable version of KHIM (Kevin's Hacky Input Manager). KHIM is a hack (as the name suggests) to allow for entry of Unicode characters on a keyboard that lacks them. Rather than interact with any host's input methods, it designates one ordinary key (the library as released uses Pause, but often change it to L2 [the F12 key on a Windows keyboard]) as a "Compose" key. This key must be distinct from the system's "Compose" key (if there is one).

When KHIM is active, pressing the "Compose" key followed by a two-character sequence enters a Unicode character corresponding to the two-character sequence. Pressing the "Compose" key twice in succession brings up a Unicode character map from which a character may be selected and inserted into the application.

A text or entry widget may be configured to use KHIM by adding KHIM to its bindtags in front of the class binding:

     package require khim
     text .t -width 80 -height 24
     bindtags .t {.t KHIM Text . all}
     entry .e -width 30
     bindtags .e {.e KHIM Entry . all}

There are commands that an application can call to bring up a control panel for KHIM (allowing for changes to the key bindings), to bring up user help for KHIM, and to save and restore the KHIM key bindings.

I wrote KHIM for several reasons:

On some machines, I'm not allowed, or don't know how, to change the system's input method to get the characters I want.
I don't want to have to learn the input methods for all the systems I use.
I occasionally have use for some pretty bizarre characters, and an "Insert Symbol"-style function comes in handy in most applications that deal with Unicode text.

It's not intended to replace a system input method, but rather to allow for entry of the occasional character that the system input method doesn't support.

As always, comments are welcome. Particularly welcome are translations of the message catalog.

RS Wouldn't it be more robust to do the bindtags invocation like this instead:

 bindtags $w [linsert [bindtags $w] 1 KHIM]

KBK Maybe - although the default list of bindtags has been stable since bindtags were introduced, so I don't think that changes are very likely.

What I do in apps in practice is:

 rename ::entry ::khim::entry
 rename ::text ::khim::text
 proc ::entry {w args} {
     eval [linsert $args 0 ::khim::entry $w]
     bindtags $w [list $w KHIM Entry [winfo toplevel $w] all]
     return $w
 }
 proc ::text {w args} {
     eval [linsert $args 0 ::khim::text $w]
     bindtags $w [list $w KHIM Text [winfo toplevel $w] all]
     return $w
 }

I should maybe export a khim::wrap procedure to allow apps to set this up by default, but I worried that perhaps some apps would want different bindings in one place from another. That's probably sufficiently user-hostile that the possibility should be ignored. I'll think about it some more.

Category Language

Category Package