Tk uses [X11] style keysyms in the generic parts of implementation and on the Tcl level. Because keysyms are a pre-[Unicode] concept this causes some disconnect on platforms like [Microsoft Windows] and [MacOS] which support [Unicode] input but know nothing about [X11] keysyms. This article tries to present the issues. See also [keysyms] for Tcl code using keysyms. As with all Wiki pages, please feel free to correct the text or add. [Benny Riefenstahl], 2003-01-05 ----- '''Basic idea and X11 implementation''' Keys on a keyboard have a platform and hardware specific designation called a "keycode." A keycode does not change when the labels on a keyboard change. Therefore e.g. the escape key and the space bar always have the same keycode on a given physical keyboard. While the same key with the same keycode that has the "Z" label on a given keyboard when marketed in the US, has the "Y" label on the german version. To abstract from hardware and platform specific keycodes, [X11] represents keys on a keyboard with "keysyms." There are two type of keysyms: Character keys: Keys that represent normal printable characters. These are determined from keycodes using a keyboard mapping table. This mapping of keycodes to character keysyms can change while the application runs. Special keys: Keys that represent some function on the keyboard. Some of these can be represented with ASCII control characters (e.g. ENTER, SPACE, ESCAPE, BACKSPACE), while others can not (e.g. function keys, cursor keys). On [MacOS X] the keycodes for these keys have a fixed mapping to keysyms. On other platforms or with more "exotic" keyboards, these keys also have to be mapped from keycodes using a mapping table. Note that modifier keys are also encoded as keysyms. In addition they are usually encoded separately as a modifier mask in key events, so one knows which modifiers are pressed at the occurrance of other key events. For C programming the [X11] keysyms have names assigned in the include file [http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/tktoolkit/tk/xlib/X11/keysymdef.h?rev=HEAD]. Except for the ASCII and ISO-8859-1 ranges, the keysym codes are not compatible with [Unicode]. To get from keysyms to [Unicode] characters an additional mapping has to be performed. Also the keysym system in it's traditional form of approximately 920 symbols does not cover the whole [Unicode] range. Because nobody wanted to maintain tables with names for all the characters in the [Unicode] standard, an algorithmic mapping was invented for characters that are not covered by the existing tables. '''Other platforms''' The keysym concept in this form is not known natively on [MacOS X] and [Microsoft Windows]. Windows has "virtual key codes" instead which serve a similar function. [MacOS X] (Carbon) uses the keycodes themself for special keys and characters in MacOS specific encodings or in [Unicode] for the printable characters. The [MacOS X] "Input Menu" and the "Keyboard Layout/IME" menu on [Microsoft Windows] allow the user to change the keyboard mapping on an application by application basis, on the fly and while the application runs. The main user-visible use of keysyms in Tk is the use of keysym names for portable key bindings. On [X11] Tk uses xlib to convert between names and codes, on other platforms Tk derives the names from and creates a runtime mapping table from that header. On Windows Tk only supports keysyms correctly for special keys, the ASCII and the ISO-8859-1 ranges. On [MacOS X] only special keys and ASCII are supported correctly currently. '''Where to go for a better implementation''' To extend keysym support on Windows and [MacOS X], mapping functions between [Unicode] and keysyms would have to be created. Another possibility would be to drop support for keysyms in general except for special keys and ASCII. Instead [Unicode] code points and [Unicode] strings would be allowed whereever keysym codes and keysym names are used right now. Input of keysym codes and keysym names could be allowed as platform extensions on those systems and as far as they work right now.