Angus Leeming <[EMAIL PROTECTED]> writes:
| It looks like there are three bugs in xforms key event handling. Two have
| trivial solutions and one will require more work.
>
| Minor 1. When composing, fl_XLookupString(xev, ... &keysym, ...) returns
| (keysym == 0). xforms should "swallow" this event just as it does XK_Shift_L
| etc. xforms should pass only the fully composed, (keysym != 0).
>
| Minor 2. fl_handle_form should pass FL_KEYRELEASE events to the
| fl_object_handler. Currently, they are discarded.
>
| It's easiest to explain the larger problem by describing what happens
| currently:
>
| (do_keyboard):
| char buffer[maxchars];
| int nchars = fl_XLookupString(&xev->xkey, buffer, maxchars, &keysym, 0);
>
| xforms now calls fl_handle_forms so:
| fl_handle_forms(form, FL_KEYPRESS, int(buffer[0]), xev);
>
| It /should/ call it
| fl_handle_forms(form, FL_KEYPRESS, keysym, xev);
>
| These two calls contain the same information, but processing of
| (int(buffer[0]), xev) is unnecessarily complex. In fact,
| int(buffer[0]) == keysym
| SO LONG AS the modifier keys Control, Alt, Shift are not pressed.
>
| They are very different, however, when the modifer keys are pressed.
>
| fl_handle_forms calls fl_keyboard(form, key, xx, yy, xev) which processes the
| event further before calling fl_handle_object(obj, FL_KEYBOARD, x, y, key,
| xev).
>
| fl_keyboard could be made to work in identical fashion using (keysym,
| xev->xkey.state) rather than (int(buffer[0]), xev). In fact, the resulting
| code would look similar to LyX's XLyXKeySym.
>
| I emphasise that modifying xforms in this way would not fix anything that's
| broken in xforms. Nothing is broken in this regard and all it's internal
| widgets behave correctly. However, modifying the code in this way will mean
| that user-defined widgets can process (keysym, xev->xkey.state) in a
| straghtforward manner. Thay would no longer have to call XLookUpString on the
| raw XEvent.
>
| Does this analysis make sense?
>
| Do you agree with my assertion that the "correct solution" is to rewrite
| fl_keyboard to handle (keysym, xev->xkey.state) ?
I think you are farily right on, I am only wondering a bit about the
| These two calls contain the same information, but processing of
| (int(buffer[0]), xev) is unnecessarily complex. In fact,
| int(buffer[0]) == keysym
issue... is this really true?
(keysym is 16bit char is 8bit... f.ex.)
--
Lgb
