Kent Karlsson wrote on 2003-08-13: > > So back to XKB. It's powerful enough to handle almost any need. It's > > formats are not ideal though. It has some X cruft, like limitation to > > 4 groups, resolution to X keysyms instead of Unicode, and general > > IIUC, UXXXX for any four-digit hexadecimal value XXXX is a predefined > keysym value mapping to character U+XXXX. (Not sure if it can handle > more than four digits, for the supplementary plane characters.) > That I believe maps to the high keysyms mentioned in the Unicode FAQ: "any UCS character in the range U-00000000 to U-00FFFFFF can be represented by a keysym value in the range 0x01000000 to 0x01ffffff". The question is, if I represent a character which already has a keysym in X (ike hebrew or european characters) with UXXXX, will applications understand it?
> > complexity, like custom names for all physical key names. The Linux > > console and Allegro also suffer from this disease. Tell me, why do I > > have to remember that the key is named `<TLDE>` in XKB and the > > resulting value is name `asciitilde` in the linux console, when I > > could have written ``~`` for both? > > That's really key AE00 and often generates some other character than > TILDE, e.g.: > AE00 means first raw, first key? That's not bad. > > I think that most key mapping tasks can be done simply as a sequence > > of mappings on unicode strings, applied one after the other. So the > > basic mapping from scancodes would uses the well-known qwerty names, > > No, thanks! (Why should one have to learn the US keyboard layout to deal > with these things??) > Sometimes it would be good, sometimes bad. E.g. a phonetic keymap is best described by reference to an english keyboard (if it's based on one). More importantly, it would achieve a uniformity - all keymaps can be plugged (or not), at any stage. With XKB, you have several stages of translation but the inputs and outputs of different stages are defined in different spaces of values, so you can't connect the translations in any other order. Example: German keyboards have Y and Z swapped (so I heard). When using e.g. a greek keymap on such a keyboard, should the greek letters be attached to the same physical positions as on a greek keyboard or should the english/greek letter correspondence be preserved? Different user might prefer different answers to this. If the german keyboard translation exchanges Y with Z, I can plug the greek translation after it or before, as I wish. If, however the German translation maps from keycodes to characters and the greek keymap also maps from keycodes to characters, it's meaningless to attach the greek keymap after the german one. Similarly, customizing XKB normally involves modifying an existing keymap at some of the stages (normally one of the last stages, where keysyms are produced). I'd rather prefer to write an additional translation that is chained before/after an existing keymap. I'm not sure whether the XKB architecture can handle it. Moreover, it's not realistic to expect that system-level keymapping is going away soon. So it'd be nice to have the same dabase of keymaps also usable to applications that want to do their own translations. Applications start with what the system produces, e.g. ASCII (especially when taliking over a terminal / telnet). So you need translations that go from there. Additionally, it'd be sometimes nice to be able to produce inverse mapping, e.g. take characters and deduce the keycodes, assuming a specific keymap was applied before. I must admit I didn't think this over well enough. Also (as you probably noticed) I don't understand XKB well enough. > > like ``q``, and following layers would translate it to a non-qwerty > > layout (if needed). This way, the amount of arbitrary names in the > > system is minimized, easying re-use in other environments. > > No, not at all. While some of the key names used in XKB layout files > are ill-chosen, many of them "come from" ISO 9995; and that's good. > Didn't know about this standard. Is it availible online? -- Beni Cherniavsky <[EMAIL PROTECTED]> -- Linux-UTF8: i18n of Linux on all levels Archive: http://mail.nl.linux.org/linux-utf8/
