Re: Determining XKeysyms

[Bill Haneman <bill haneman sun com>]

Hi Matthew:

Nice to hear from you, and I am especially glad that you are looking at
the at-spi APIs (apparently).  It turns out that you have asked a firly
subtle question that is sort of at the tip of an iceberg.

On Mon, 2003-03-03 at 02:54, Matthew Garrett wrote:
> I'm currently working on allowing Dasher to write text to arbitrary 
> windows. The accessibility library's implemented methods for doing this 
> seem to require me to know either the keycode or keysym of the character 
> concerned. 

This is a general requirement for doing synthetic input on X; how does
Dasher deal with this issue already?  The short answer is that you do
need to know keycodes (ultimately) in order to do synthetic input,
unless you are using XIM.  The at-spi allows you to specify keysyms
instead, and it will pick an appropriate keycode for you.  Of course
there are sometimes more than one keycode that will generate the same
keysym - the exact keycode used is undefined by the API in this case but
it should not matter.

AT-SPI does have API for synthesizing keyboard input on a UTF-8 "string"
basis (but please read on :-)  Also, if you are using AT-SPI-aware
applications, you can use text-editing APIs to change/insert/delete
UTF-8 strings without involving the keyboard or X server at all, i.e.
without simulating physical keypresses.

> The problem is that users may have customised alphabets 
> containing arbitrary characters, and expecting them to determine the 
> keysym name themselves seems excessive. 

Could you please explain this situation more thoroughly, to explain the
exact conditions under which it comes up?  It is unclear what a
"customised alphabet" or an "arbitrary character" means in your context.

I will take a guess that you mean, more-or-less, that a user may wish to
input characters that might be chosen from anywhere in the unicode
character map.  In the case of a 'traditional' onscreen keyboard this
problem doesn't come up very directly since (just as for the user of a
physical keyboard) not all unicode characters are represented on the
keyboard.  That is, when using a 'Latin'/english keyboard it's not
trivial for me to input say, a Hebrew aleph or greek omega (or for that
matter, a Euro sign ;-).  There are no keycodes for these keysyms
available on my keyboard.  And although all of the examples I just gave
do have standard X keysyms defined for them, the same is not true for
the general case.

I have a related question about your presentation layer.  For a
'traditional' onscreen keyboard, each key must (at any one moment in
time, depending on the keyboard "state") map to either a character,
glyph, string, or action of some kind.  In the case of glyphs or
strings, the string needs to be presented to the user.  If we are
modelling a physical keyboard, we obtain the range of available
keycodes, convert them to keysyms and/or strings by querying the X
server, then present those strings to the user as "keycap labels".  We
have the advantage over physical keyboards of being able to dynamically
change those labels).  In the case of Dasher (and word-completion
generally), I take it that you are getting your input from
internationalized strings (for instance UTF-8 strings) - is that
correct?

The presentation layer is relevant to this for the following reason: If
you start with a physical keyboard, you can go from the keycodes and
construct a set of available symbols/glyphs quite easily.  But if you
start with the symbols/strings (as you apparently do), then the mapping
back to the keycodes becomes tricky - in fact there may be no currently
available keycodes that map onto the symbols of interest.

XIM is the API usually used for inputting character data that isn't
mapped directly via keysyms.  How does Dasher handle this now (i.e. for
fully internationalized text) ?  Unless you use at-spi's text editing
APIs, you cannot input text (synthetically) which could not be input
physically (either directly from the keyboard's keysym map, via a
'compose sequence', or via an X Input Method (XIM)).

> Is there a trivial (or, at 
> least, not hideously awkward) method of going from, say, " to 
> XK_quotedbl?

This particular example is one that could of course trivially be handled
in a lookup table.  But the more general case of finding a
keysym/keycode or compose sequence for a unicode point is not so easy -
and I expect it's the one you are really interested in.

As I mentioned above, at-spi has API for generating/synthesizing
keyboard input based on an input string (as well as via specification of
a keysym or keycode).  However this API is not currently implemented; it
is vital for internationalization but our initial release targets only
latin locales.

I suspect strongly that if Dasher is currently targeting "latin" or
related character set locales (or in fact any locale whose character set
is contained in the X11/keysymdefs.h definitions), then you can get by
without using the "string" API, by doing your own mapping from unicode
characters to keysyms.  One way of doing this is by building your own
keysym/string table from calls to either

XkbTranslateKeysym  
[more general, requires that XKB be enabled] OR

XLookupString.

In either case you will need to build a table which includes the effect
of modifiers.  For English-only keyboards, just "Shift" should suffice;
for other languages and keyboards you may need to check multiple
"groups" and "levels" (to use the XKB terminology).  From there, mapping
from unicode characters to keysyms would be a straightforward search. 
This search could be simplified by noting at the outset that
keysym==ascii-code for the ASCII character set, etc. so it need not be
inefficient.  This would fail for unicode points not included in
xkeysymdefs.h, but most european languages (and possibly Hebrew, Arabic,
Japanese, Korean, and Thai) could be handled in this way, provided the
user had the appropriate keyboard.  [Note: In order to input characters
not directly available on the user's physical keyboard, XIM is
required].

The intent of the AT-SPI "string-based" synthesis API is to hide this
complexity from clients, but as I said it's not yet implemented
[bugzilla #92143].  If you are planning to use/rely on this feature then
we can consider expediting at least a partial implementation (for latin
character sets, for instance). 

-Bill

> 
> Thanks,
-- 
Bill Haneman <bill haneman sun com>