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 122117 - gok should generate alpha and freq-table kbds at runtime
gok should generate alpha and freq-table kbds at runtime
Status: RESOLVED FIXED
Product: gok
Classification: Deprecated
Component: general
unspecified
Other Linux
: Normal normal
: ---
Assigned To: bill.haneman
bill.haneman
Depends on: 123284
Blocks: 122112
 
 
Reported: 2003-09-12 13:45 UTC by bill.haneman
Modified: 2004-12-22 21:47 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
patch to provide this capability (17.88 KB, patch)
2003-09-26 07:25 UTC, bill.haneman
none Details | Review

Description bill.haneman 2003-09-12 13:45:32 UTC
At the moment all of gok's non-XKB-generated keyboards (such as the alpha
keyboard and frequency-table-based keyboards) are static.

It makes more sense to generate these at runtime; also it means they can be
trivially localized.  At the moment localizing them is a major problem.

I suggest for instance they be create from strings like "abcdefg..."
and "etaonr...", etc. with appropriate notes to the translators.

Alternately, the 'alphabetic' keyboard could be generated from the known
collation sequence of the target locale, I guess, but perhaps the collation
sequence isn't exactly what the user expects to see in an alphabetic keyboard.

I don't think this is a big task.
Comment 1 bill.haneman 2003-09-24 16:46:33 UTC
David: I've almost got a patch ready for this.  Since actually _using_
these keyboards is technically a feature, we shouldn't expose them in
the UI before we branch for 2.5.  However I think we could introduce
the relevant strings sooner, to give the translation teams the maximum
time to work on them.

Comment 2 David Bolter 2003-09-24 17:14:02 UTC
Sounds good.
Comment 3 bill.haneman 2003-09-26 07:25:49 UTC
Created attachment 20308 [details] [review]
patch to provide this capability
Comment 4 bill.haneman 2003-09-26 07:31:07 UTC
Remaining/open issues with above patch:

* i18n results and translator notes extraction to *.po not tested yet
  (expected to work)

* generated keyboards tend to be too square for dock mode;
  need layout mode for "short, wide" keyboards

* layout is left-to-right and top-to-bottom in sequence; need 
  to choose row,col based on number of selections required
  for frequency table case.  Filing new bug for this.

* no ChangeLog entry yet

* This patch hacks 'Keyboard', i.e. makes the Compose keyboard
  use the alpha-frequency keyboard instead of the core keyboard.
  Prior to committing, this hack should be removed from main.c.

Comment 5 bill.haneman 2003-11-04 13:42:33 UTC
partial fix now in HEAD; GOK creates appropriate keyboards on the fly,
but they aren't laid out properly yet (that requires a fix for 123284).
Comment 6 David Bolter 2004-03-01 16:51:24 UTC
Just a note that gok_keyboard_get_alpha_by_frequency is not in the
code path yet -- is in fact currently commented out. (aside: future
work on bug 135841 will require this code path for testing.)  

I suggest that for prime time, we move the this call to the case where
the user (gconf) setting for using an xkb keyboard is false, and there
is no locale specific premade keyboard.
Comment 7 bill.haneman 2004-03-01 17:09:23 UTC
David:

GOK does actually create these keyboards now (but doesn't branch to
them); see main.c line 1561.  And I think it should; the only issue is
what keyboard is branched to by the Compose key, IMO.  There may be
cases where different keyboards need to coexist.  If a user created a
custom keyboard which branched to "alpha", the alphabetic keyboard
would appear.  Likewise for a keyboard named "alpha-frequency".

I suggest a setting for GOK to indicate the type of "alpha" keyboard
to use:

* alphabet keyboard laid out by "collation sequence"
* alphabet keyboard laid out be frequency

though I would not expose the wording "collation sequence" to the
end-user, of course.

Comment 8 David Bolter 2004-03-01 18:51:33 UTC
I wouldn't use "collation sequence" because I don't know what it means
(blush).  :-)
Comment 9 bill.haneman 2004-03-07 14:59:33 UTC
This code is in place now (though the user doesn't see it in normal
operation).  We should open an RFE for allowing the user to select the
preferred text keyboard type.