After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 135841 - gok keyboard layout algorithms incomplete
gok keyboard layout algorithms incomplete
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other Linux
: High major
: ---
Assigned To: David Bolter
David Bolter
AP3
Depends on: 135839
Blocks: 133545
 
 
Reported: 2004-03-01 16:39 UTC by David Bolter
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
small diff to show desired upperl layouts (1.02 KB, patch)
2004-05-12 14:59 UTC, David Bolter
none Details | Review
small patch which may resolve this bug. (1.82 KB, patch)
2004-05-12 20:43 UTC, bill.haneman
none Details | Review

Description David Bolter 2004-03-01 16:39:18 UTC
The gok keyboard layout algorithm(s) is(are) not yet part of the regular
build.  Further required work and consideration:

- UI preferences, 
- different keyboard weightings (e.g. upper left, lower right, center)
- testing
Comment 1 bill.haneman 2004-03-30 13:08:57 UTC
David: if you now run gok --keyboard alpha-frequency you'll see that the UPPERL
layout isn't working for this keyboard.
Comment 2 bill.haneman 2004-04-29 17:05:44 UTC
raising priority now that we have exposed the frequency-table keyboards in the UI.
Comment 3 David Bolter 2004-05-10 18:15:17 UTC
I think this has resolved. 

Bill can you confirm?
Comment 4 bill.haneman 2004-05-11 16:07:49 UTC
It hasn't resolved... the UPPERL layout still isn't implemented: the frequency
alpha keyboard attempts to set KEYBOARD_LAYOUR_UPPERL but it doesn't result in
layout of keys by scan-order, it still lays them out left-to-right and then
top-to-bottom.
Comment 5 David Bolter 2004-05-12 14:59:51 UTC
Created attachment 27639 [details] [review]
small diff to show desired upperl layouts

I've got to run off to a meeting, but I thought I would show how to get test
out the upperl layout code...
Comment 6 bill.haneman 2004-05-12 20:42:10 UTC
Thanks David.  Is there a reason this code was #define'd out?  I removed the
#ifdef bracketing, then changed gok_main_ds to pass the keyboard's own layout
type to gok_keyboard_layout, which seemed to fix the issue.  I attach my
modified patch; there are some small issues for the future, for instance we
assume that frequency keyboards should be laid out in UPPERL which isn't, for
isntance, the case for access methods like single-selection.
Comment 7 bill.haneman 2004-05-12 20:43:18 UTC
Created attachment 27650 [details] [review]
small patch which may resolve this bug.
Comment 8 David Bolter 2004-05-12 20:47:02 UTC
It was #defined out because I had wanted to test it more.  IIRC the center
weighted frequency algorithm isn't implemented yet (although strangely I
remember working on it).  We could make that a separate bug if you wanted to
close this one.

The other corner weighted algorithms are just variations of the UPPERL...
Comment 9 bill.haneman 2004-05-12 20:58:41 UTC
I don't see any of the other corner-weighted algorithms yet, but that's fine
since our scanning methods all scan RTL/top-to-bottom now anyhow.  That's an
i18n bug that needs to be filed I suppose.

Should we just apply the patch (second one) above, then?  And will you do the
honors, or shall I?
Comment 10 David Bolter 2004-05-14 13:07:37 UTC
Done.  Thanks Bill.
Comment 11 bill.haneman 2004-05-20 11:34:12 UTC
I believe we can close this bug and leave the center-weighted, etc. layouts in
their own RFEs.