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

[Danilo Segan <dsegan gmx net>]

Bill Haneman <Bill Haneman Sun COM> написа:
>> 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.

It did happen for me once with 2.4.0 and gok 0.9.3. I cannot reproduce
it steadily (actually, I cannot reproduce it at all anymore), bit it
did happen.

> 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.

Ah, I see. So, might the solution for this be to put all the
potentially useful keys into higher levels? (I'll try that later
today too, since I've already got a six-level Serbian keyboard which
includes all of English alphabet at http://srpski.org/dunav/ --
English is at 5th and 6th levels).

> 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.

Yes, I'm willing to help here. There would probably be something that
can be reused from libxklavier (used by GSwitchIt -- I believe it
reads XKB state directly) from freedesktop.org. I don't know how much
does this fit into a11y goals.

> 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 read something about it in the README. I'll check all the
conditions, and see if anything changes.

> 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). 

Yes, I understand that. As mentioned above, I imagine this solved
with a common collection of multi-level keymaps (perhaps I might even
develop a 64-level keymap [max for XKB I think] which would include
all the keysyms currently in use by GOK translations -- would you
find this interesting, or would it be a resource hog?)

> 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.  

So, how would a solution of XKB keymap which comes with all the
neccessary keysyms suit this solution?

It might even be possible to "merge" (xkbcomp -merge) all these
keysyms to the X server on startup, so we would not destroy the
user's current keymap. Though, I'm not sure on this, so I'll have to
look into it.

> 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).

Btw, I was unable to determine how to switch between any of these (I
just get current XKB map). I admit that I didn't investigate it much.

> 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.

Yes, when I'm on IRC, I'm "danilo" in #gnome and #i18n -- feel free to
ping me, and perhaps invite me to a more appropriate channel (I'll
check #a11y if that one exists).

I'll follow back later today when I get back from town and
invistigate a bit more.


Cheers,
Danilo