GNOME Bugzilla – Bug 123284
gok layout engine ignores GokKeyboard.LayoutType
Last modified: 2004-12-22 21:47:04 UTC
GOK's layout engine (for auto-layout of GOK buttons) needs to provide for 'dock' mode better when creating alphanumeric keyboards. At present these auto-layout keyboards tend to be square, which is no good when GOK is in DOCK mode. Also, the layout engine needs to be able to lay out keys according to ease-of-selection (i.e. total selection steps required to select and activate a key, in scanning modes). This is important for frequency-based alpha keyboards as well as any other keyboards where we want most-frequently-used keys to appear in the 'upper left' (i.e. early in row and column scan lists). I suggest that we make gok_keyboard_layout() pay more attention to the pKeyboard->LayoutType. David, can you elaborate on the meanings of layout types KEYBOARD_LAYOUT_UPPERL and KEYBOARD_LAYOUT_CENTER? It appears that perhaps KEYBOARD_LAYOUT_UPPERL should be renamed KEYBOARD_LAYOUT_FREQ (since in some locales we may want to scan right-to-left, etc.); we could then use KEYBOARD_LAYOUT_FREQ and KEYBOARD_LAYOUT_FITWINDOW to determine how gok_keyboard_layout should behave. However, if GOK is in 'DOCK' mode we will want both of these 'attributes' to be set, so perhaps the LayoutType needs to be a flags field instead of just an enumerated type, i.e. typedef enum { KEYBOARD_LAYOUT_FREQ = 1 << 0, KEYBOARD_LAYOUT_FITWINDOW = 1 << 1 } KeyboardLayoutFlags; typedef guint16 KeyboardLayout; ('normal' would correspond to no flag bits set). We could collapse the 'LaidOut, RequiresLayout' booleans into this too I guess, if we wanted.
david, ping... are you looking at this one? Also I'd be grateful for feedback on my questions above.
Hi Bill. I'm having time management problems, but here is a quick reply. I've separated (rightly or wrongly) the concept of keyboard "shape" from the concept of "layout" of the keys. Have a look for this code in main and you can try different shapes: if (gok_keyboard_layout (pKeyboard, KEYBOARD_LAYOUT_NORMAL, /*KEYBOARD_SHAPE_WIDE KEYBOARD_SHAPE_SQUARE*/ KEYBOARD_SHAPE_KEYSQUARE, FALSE) == FALSE) I recommend trying the wide shape for dock mode. The layouts are not hooked up (as you note), and we do need to visit this. I began planning an algorithm a couple of weeks ago but got redirected.
haven't tried yet. I do agree that layout-shape and layout-order are two separate aspects. How about we make the layout something other than an enum? We could have bitfields, or GokLayout could become an object in its own right (the latter would be more flexible and probably better).
I like the latter. We need this for i18n right?
this is needed for i18n of alphabetic and frequency keyboards. also for asian keyboards I think, but there are other dependencies for large-character-set asian keyboard support.
David: this seems to be one of only three open i18n issues for 2.6. Needs fixing soon I think. The 'UI for aux wordlist' bug needs fixing for feature freeze (Jan 12), this one can wait a few more days I think (as it's a bug/unimplemented but 'existing' feature) but it's feature-ish enough that we should not delay IMO. This can unblock 122117 above (which I think was mostly-working in CVS or your sandbox), and we're well on our way to having i18n GOK.
ping for David; any progress on this one? I'd like to see it either fixed in the next, say, week or else postponed to 2.8 since it's potentially a significant bit of code. What do you think?
we have a rudimentary version of this working. a couple of basic rectangle variations. is this enough?
possibly: how does it handle layout-by-frequency, and 'wide' layouts? these are probably the most important ATM; 'wide' for dock-mode GOK, and by-frequency for the dynamically laid out frequency keyboards.
This got lost in my slush pile. I'm getting back to this now. Bill, can you remind me -- how do I try out alphabet.kbd? Is this hooked up?
marking severity 'major' since it blocks frequency-arranged dynamic keyboards.
do not use alphabet.kbd, it is deprecated. you will see that the alpha-freq keyboard (and the alpha keyboard too) are dynamically generated from (localized) strings. I think if you branch to the "Alpha-Frequency" keyboard you'll follow the right codepath (i.e. get a dynamic keyboard which asks to be laid out in frequency-order).
Great - that helps thanks. I'll take a look.
Status: The keyboard is shown but frequency is ignored. Also, "shift" doesn't seem to have an effect. Here is how I am proceeding on the freq algorithm: create a utility function based on cell row and column (keeping in mind i18n issues like right to left scanning), assume list of keys are in order of highest frequency to lowest frequency key, attempt to place the next key in the cell with best utility, and if it doesn't fit, try the next highest utility cell.
Further to this, I think if we have an UPPER_LEFT solution, the resulting keyboard can be easily flipped vertically and/or horizontally as needed (by scanning direction)... and I think you are correct earlier that we should give this a more generic name. And the CENTER algorithm should be okay across locales.
ok, you can log a bug (assign it to me) regarding the Shift key issue. thanks for the other work. My proposal vis-a-vis UPPERLEFT/FREQ was to make is a layout attribute/bitflag (freq) since there are two mostly-orthogonal layout issues at hand: (1) the arrangement/order in which the keys are placed; (2) the aspect ratio/geometry of the keyboard. #1 should as you point out depend on the scanning direction, so if you changed from LTR to RTL, the keys should be laid out in the opposite direction IMO. I still don't understand what is meant by CENTER, nor your comment about it being 'ok across locales'.
I think we are mostly on the same page. By CENTER I am talking about putting the most frequently used keys in the center of the keyboard which is good for pointer users with a limited accurate range (pointer accuity). CENTRE wouldn't normally be chosen for (the existing) scanning access methods.
re CENTER: gotcha. makes lots of sense to me.
Just a heads up - I didn't clear away much time for this this weekend. I'm preparing a patch for upper left weighted, and I will likely commit it (in a harmless way) tonight so that it can be polished up post Monday. I'm not entirely happy with the "gok_keyboard_get_alpha_by_frequency" codepath as it is hanging on gok exit. I haven't had time to investigate.
BTW, the algorithm changed since my 2004-02-05 10:35 comment. Also note that the new code in gok-keyboard.c is ifdef'ed out for regular builds...
Created attachment 24215 [details] [review] this patch has already been applied to gok cvs head
Note to test this one needs to change: pKeyboard = pKeyboardFirst = gok_keyboard_get_core (); to: pKeyboard = pKeyboardFirst = gok_keyboard_get_alpha_by_frequency (); and to uncomment /* #define TEST_GOK_FREQUENCY_BASED_KEY_PLACEMENT */ in gok-keyboard.c
removed GNOMEVER2.5 keyword since remaining issues will need to wait until post-2.6 I believe. David: weird thing about the patch, it seems to be using freq-based layout based on the KEYBOARD_SHAPE_KEYSQUARE layout, which doesn't make sense... the layout algorithm should be independent of the layout shape heuristic. At least - even if FREQ keyboards imply SQUARE, it should be possible to specify SQUARE keyboards that don't use frequency-based layout.
marking ASSIGNED on behalf of David.
I thought I had responded to this a while back but I must not have logged in or something. I used the KEYBOARD_SHAPE_KEYSQUARE just for testing. The shape of the keyboard is indeed separate from the layout, which was the reason I split those concepts in my code design. BTW I'm happy with the code so far. Implementation of Center weighted layouts will be non trivial unfortunately. FWIW I don't think this bug is critical for accessibility. It is definitely an internal "must have", but won't deny anyone access to the desktop in the mean time.
OK David; let's close this bug and open RFEs regarding the layout shape stuff and the CENTER layout,,, my understanding of the remaining issues: * need CENTER layout * need two kinds of control over shape:
oops, hit return... two kinds of control over shape: #1 : row/column aspect ratio #2 physical aspect ratio (i.e. for wider keyboards when using EXPAND, etc.) - Bill
David, why don't you do the honors (closing this bug and opening the RFEs/bugs).
...with pleasure (though technically we aren't done -- the RFE can take over) Please see related RFE bug 135841