[g-a-devel]Re: gok 0.9.3 released - keyboards now i18n-ready

[Bill Haneman <Bill Haneman Sun COM>]

On Sun, 2003-11-16 at 02:30, Danilo Šegan wrote:
... 
> What you're mostly interested in is probably the fact that the
> onscreen keyboard seems to function all right for input of Serbian
> cyrillic characters, if I've got a correct XKB map in place.

That's good to confirm, thanks!

> Also, I experienced a bunch of other problems.
> 
> Apparently, not all strings are extracted for translation from
> main.kbd.in (eg. nothing shows up for "Compose"). Also, even though
> "Menus" is translated and later merged into sr/main.kbd correctly, it
> didn't show up either. Actually, the entire first screen of GOK was
> untranslated for me.

I forgot to mention that GOK doesn't already automatically look in the
correct locale-specific directory for its keyboards (see bug/rfe ).  For
the time being you must change the gconf key
/apps/gok/keyboard_directory from $prefix/share/gok to
$prefix/share/gok/$locale (where $prefix is the prefix into which you
installed gok, i.e. /usr or /opt/gnome-2.5, etc.).  For instance you
could change it to /usr/share/gok/sr.

> Next, when I switched from one mode to other (eg. from main screen to
> GOK, and back), window size was automatically reduced, and performing
> these steps several times led to getting smaller and smaller
> fonts (I cannot reproduce this either). 

This seems to be a regression in gtk+ or metacity; we "fixed" this
problem once before ;-).  I guess you are using gnome HEAD then?  I
don't believe this happens with 2.4.X GNOME and gok-HEAD - if it does
please let us know.

> 
> When I tried to exit from GOK section using "Quit GOK", button "Really
> Quit!" for confirming exit didn't do anything (except for
> flashing). This one I can reproduce steadily.

Yes, fix in progress for this one.  Thanks for catching it!

> Also, I noticed that GOK actually produces the keycodes, and not the
> keysymbols corresponding to characters. This means that I must have
> appropriate Serbian map so that characters would correspond with
> reality (and the one I used [and developed] will be included with
> XFree86 4.4, which is not yet released).

Yes, this is a current limitation with GOK.  It turns out that the X
server can't really accept keysyms that aren't loaded in the current
keymap (without really big changes to at-spi internals).  We do hope to
fix this someday but it may have to wait for OpenI18n to get completed
and become widely available.

> Also, if there are several groups loaded, and I switch to other
> keyboard group, glyph images on the keyboard don't correspond at all
> to the characters that are output (eg. if I switch to en_US XKB map
> in XFree86 4.3, and use Serbian locale for GOK, it outputs latin "B"
> instead of cyrillic "Б" which is showed on screen).

If you quit GOK and restart with the new group this should work.  GOK
doesn't listen to group changes yet.  Perhaps you can help us debug and
test this feature, which we realize is important.
 
> I've expected that pressing "Shift" images with mouse in "Compose"
> mode would also show the 2nd level of keyboard, but that didn't
> happen -- if I press the real Shift key on keyboard, it happens all
> right. Ditto for ISO_Level3_Shift.

GOK is getting this info from XKB.  We need to determine what's
happenning in 'Compose' mode with respect to the modifier bits and
group.  Since GOK is reacting correctly to the true shift key, we know
that the information is available.  Are you sure you didn't accidentally
turn off StickyKeys at this point?  Also, note that in order to get the
shift behavior working right you need to be using GOK either in dwell
mode, or via an extended X Input device (not to be confused with XIM "X
Input Method").  If you are running GOK in 'core pointer mode' and using
'direct selection', there are conflicts with the gtk+ toolkit and X
server that will break use of GOK modifier keys in some situations.

> I think the correct approach would be to read the data about groups
> and levels from X server, or at least to always output what is shown
> on screen (i.e., output a keysym, and not a keycode). Using
> translations of "level0|..." strings seems inappropriate, especially
> so in cases like that of Serbian where there are several keyboard
> maps with slight differences, so it would not work correctly with
> some of them.

Outputting keysyms for the XKB-generated compose keyboard isn't feasible
and won't work right anyhow in lots of cases - the keysym has to be in
the current keymap _somewhere_.  Keysyms can however be output for the
'ordered alphabetic' and 'frequency order' keyboards (see below). 

We must use the 'level' strings for alphabetic and frequency key tables,
which we cannot get from the X server or keymaps; I haven't been able to
identify a reasonable alternate mechanism.  If the user uses
ordered-alphabetic or frequency-order keyboards (not a common case yet),
then only one set of keymaps can be used; IOW the translations must
assume a keymap set, at least for those specific keyboards.  

Note that GOK uses two different kinds of compose keyboards; one set
comes directly from XKB and thus should reflect the 'physical' keyboard
if one is present.  The other types of compose keyboards are the
'ordered alphabetic' and 'frequency order' keyboards, which operate
independently of the X keymap (except that the keysyms in these
keyboards must be somewhere in the currently-loaded keymap).
 
> Okay, I didn't have accessibility features turned on (GOK warned me
> about it at start up), so that may be causing some of my problems
> (though I believe that's only the reason why my "Menus", "Toolbars"
> and "UI Grab" buttons are disabled, though I may be mistaken).
> 
> If you wish, I may file any or all of these as bugs, and I can
> probably provide more info if you tell me what to look at. Of course,
> I don't have much clue about any of the stuff GOK needs to 
> perform, so be sure to brief me on exactly what you need done, and
> what info you may require.

Thanks a lot for helping identify some of these issues.  Most of them
are known problems that should be getting fixed before 2.6, but a few of
the issues regarding keymap-switching are fairly tricky and may have to
wait for a later edition of GOK.  Perhaps we can chat on IRC sometime
about those issues, and you can help us test our implementations a bit.

best regards,

Bill
 
> Cheers,
> Danilo