Re: Determining XKeysyms

[Matthew Garrett <mjg59 srcf ucam org>]

On Mon, Mar 03, 2003 at 12:41:51PM +0000, Bill Haneman wrote:

> 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 the moment, Dasher simply writes into a text pane above the Dasher 
window. Users can then copy and paste out of here into an application. 
It would be preferable to us to be able to pass this directly (it's a 
feature request we've had for the Windows version, so doing it for Linux 
as well would be sensible for us).

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

Yes, the former would be absolutely wonderful, but as you say there's a 
nice note in the source saying that it's not implemented :) It'd be 
preferable to allow it to work with all applications rather than just 
AT-SPI aware ones from our point of view, but that might be a reasonable 
solution for the moment

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

Dasher uses UTF8 internally. The characters displayed to the user are 
determined by the alphabet chosen - we currently only supply alphabets 
for various European languages, but the code allows setting of 
right-to-left input and ought to display any UTF8 character that the 
user has sufficient font support for (though I haven't tested this 
terribly well recently). The GTK 1 version is limited to ISO-8859 
encodings, but we're hoping that the GTK 2 port will have functionality 
equivilent to the Windows port in this respect.

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

Yes, that's 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.

Indeed :)

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

Currently we just don't deal with the problem at all, which is fine for 
a separate application but less useful for something that's interacting 
with the desktop environment as a whole.

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

Yup.

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

Yeah. That's a possibility - is there an existing mapping available, or 
would this be useful time well-spent?

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

That would be great from my point of view, but implementing something 
myself is also an option. I also need to look into the Windows interface 
for this stuff and see what messy details I need to go into there.

Thanks for the detailed response,
-- 
Matthew Garrett | mjg59 srcf ucam org