On Wednesday 18 December 2002 3:52 pm, Andre Poenitz wrote:
> On Wed, Dec 18, 2002 at 10:26:09AM -0500, Kuba Ober wrote:
> > So, there are just a few simple steps that take place:
> > 1. Keyboard scancodes result from physical keypresses
> > 2. current modmap is used by the X server to map scancode sequences to
> > keysyms 3. keysyms are passed to the application via Xlib
> > 4. it's up to the toolkit to decide what to do -- AFAIK the expected
> > behaviour (somewhat screwed in Qt) is to simply pass keysyms in some
> > toolkit-transcoded form to the widgets as proper events
> > 5. for all documents, the application will typically pass the letters
> > that are inside the document's encoding set to the document, and should
> > display question mark or box or something similar for letters wich are
> > outside of document's encoding set.
>
> Where in that scheme happens Composing?
This is what happens in the xforms frontend. I guesss that it explains the
general case too. Basically if XmbLookupString returns a null keysym, then we
don't pass the event on to the widgets.
Xevent * xev = ...;
switch (xev->type) {
case KeyPress: {
unsigned char keybuf[227];
KeySym keysym = 0;
// a wrapper for XmbLookupString
int kbuflen = fl_XLookupString((XKeyEvent *) xev, (char *) keybuf,
sizeof(keybuf), &keysym);
if (kbuflen < 0)
// error
return;
/* keysym == NoSymbol during multi-byte char composition.
Eg, I've typed Multi_key-a but not yet ' to give \'a
Silently swallow these partial-compositions. */
if (keysym == NoSymbol)
return;
/* Ignore modifier keys as they don't cause action and are
taken care of by the LookupString routine. */
if (IsModifierKey(keysym))
return;
/* Dispatch the key event */
FL_FORM * keyform = ...;
fl_handle_form(keyform, FL_KEYPRESS, keysym, xev);
}
break;
}
--
Angus
