GNOME Bugzilla – Bug 108137
GOK modifier map code needs revision
Last modified: 2004-12-22 21:47:04 UTC
GOK's code for gok_modifier_keymasks needs revision, to reduce the amount of strcmp that is going on, to consolidate the usage of modifiers and modifier names in GokKey structs and in the modifier map, in gok-spy modifier event detection and keyboard updates, etc. filed after conversation with Simon. This could give us big performance improvements in creating new keyboards, processing modifier state changes, and elsewhere.
bumping up severity since the performance issue is noticeable on SOlaris.
see also 107211.
see also 107211. Perhaps this will need to wait until post-2.4.
note that this _will_ need to be fixed before we can work effectively with non-latin keyboards!
Apologies for spam... marking as GNOMEVER2.3 so it appears on the official GNOME bug list :)
Just to be clear, this is an i18n issue (among other things)?
yes indeed, it's an i18n issue; the tracker bug gives some reasons why. See the dependency tree for more info. I didn't include the i18n keyword in this bug since the bugs which it blocks include it.
There are the following concerns/issues here (at least): (a) X and XKB use 'levels' and 'groups' for dealing with keycode-to-keysym mapping (i.e. for keys that generate context-dependant characters/glyphs) (b) GOK currently stores modifiers by name only, and uses strcmp to compare a gok-key's labels with the current modifiers. This means not only lots of strcmp, but the need for multiple conversions to and from X levels/groups/modifier-masks and GOK modifier names. (c) the values of X modifier mask bits available and their correspondance with levels and groups depend on the server, etc. etc. and therefore need to be initialized/determined by GOK at runtime. (d) user-familiar 'symbolic' modifier names such as NumLock don't have consistent bit values (see above), though modifiers like MOD2 and MOD3 do. We'll need to look at the XKB API a little more closely, look at the info we are getting from XKB events and the info we need in order to pass at-spi a key-synthesis command, and try to determine the optimal internal representation for a modifier in GOK. In doing so we also need to consider how to accommodate hand-crafted keyboard XML files which specify modifier-label combinations. The result should be something much more performant, capable of dealing with multiple modifiers (>2) at once, and more i18n-ready. Because this has both performance and i18n impact I am bumping up the priority.
closing this bug, since I've implemented the above behavior. However there's still room for improvement in the keymodifier code; at the moment we won't be able to use GOK-specific modifiers, the only ones that work now are those already 'known' by Xlib. There's some code that's available for this but it's not connected; basically we need to keep the 'old' gok-modifier-strings around and test them if the input string doesn't match a known XKB/Xlib modifier name, and likewise we probably should include some keymask bits for gok-specific modifiers in our returned keymask value from gok_spy_get_modifier_mask. But what we have now should handle the existing cases and 90% of user needs. I'll file an RFE about this minor regression/extension. However there's still a performance bottleneck which turns out to be caused by the dynamic keylabel-resizing which occurs when the key labels change (due to a modifier event).