GNOME Bugzilla – Bug 136482
Consider two new keyboards: Navigation & 10-key
Last modified: 2004-12-22 21:47:04 UTC
Consider adding two new keyboards to GOK. Navigation: UI Grab & Activate together do a great job making a large number of tasks very efficient. Nontheless, there are places where UI Grab fails, or isn't the right approach. Consider adding a Navigation keyboard to GOK which contains "Tab", "Shift-Tab" (or "Back-Tab"), the arrow keys, "PgUp", "PgDn", "Home", "End", and "ESC". Perhaps one or two other keys as well. 10-key entry: there are a number of situations in which a user is only entering numbers. Doing this with the existing Compose keyboard, especially as a single-switch user in the traditional layout (with the numbers at the far right) isn't very efficient. For this situation, a 10-key keyboard (or really the full typical 17-key Numeric Keypad) would be a much better choice. Down the road it may be possible for an application to indicate to GOK that a particular text-entry field is a "numbers only" field, in which case GOK might switch to this keyboard automatically.
I'd call the "10key" keyboard a "numeric" keyboard. Seems like a good idea, and one that we've considered. Of course it's easy to create such a keyboard with GOK's keyboard editor (now), but having one built-in and/or accessible from the "standard" installed GOK keyboard suite would be nice. There are two ways to go here: 1) hard-code one, similar to the hard-coded "qwerty" keyboard; 2) build one from the current XKB numberpad keyboard geometry "section". #2 would be more elegant, but it's not clear how easy it is to identify the numberpad section. It would also require that the current XKB keyboard definition has a numberpad section (most do). #2 would also ensure that the numberpad keyboard was properly localized, since the exact placement of numberpad keys and symbols may not be fully standardized. #1 would be really easy to do of course. I'd suggest combining these two keyboards into one keyboard, with a "shift" or "numlock" virtual key which would allow the same GOK keyboard to do navigation and number entry. Again, this would be pretty simple.
This would be a 2.7.X feature, probably, though perhaps we could bundle a hard-coded numeric keyboard with 2.6.1, strictly as a sample (i.e. not connecting it to the default GOK keyboard set).
Created attachment 25310 [details] [review] xml.in file for numberpad keyboard, including Tab and Shift-Tab (untested)
the attached keyboard is pretty rough (several obvious bugs) but I just hacked it up fast. It conforms approx to ISO 9995-4, so there is in fact a "standard" applicable for numeric keypads, suggesting that we might not have to extract this from the XKB description.
BTW I got the shifted-vs-unshifted keycaps backwards in the attachment. I also notice that GOK's "qwerty" keyboards keycaps don't update with the Shift modifier (though the output does properly shift case). will file a bug on that.
Created attachment 25312 [details] [review] more correct numberpad keyboard (remember to intltool-merge it)
Remaining question is when to branch to this keyboard; I suggest we provide it as a branch target on a gok keyboard, but which one? Should we add a key to the 'GOK' keyboard? Or add one to the bottom row of Compose (currently used only for Text Manipulation? David?
My vote would be on the Text Manipulation row. I haven't tried any of the recent patches to support Chinese; how does the user indicate s/he wants to input in a different language? Is it only based on the user's locale? I bring this up here because putting another key on the Text Manipulation row for switching text-entry languages might also make sense...
Just as any user would use the Keyboard Indicator applet, GOK users can use it to change their keyboard definition as seen by the X server, etc. For the "special" languages which really require input methods or something beyond what an XKB keyboard definition can provide (primarily Chinese, and Japanese for users who don't wish to use only Hiregana or Katakana), this is governed by a combination of locale (which can be set on the fly in the shell), and user-specified "compose" keyboard (see bug #136454). At the moment, user-specified compose keyboards must be changed in the Settings dialog, but of course any user wishing to create a "my keyboards" keyboard may do so, and introduce that into the GOK branching keyboards list in any way s/he likes. In practice, a locale-specific custom branching keyboard probably will want a branch key which takes it to the XKB-specified compose keyboard as well, so that a user may use physical keyboard emulation as well as GOK-input-method character insertion.
fixed in CVS