On Monday 09 December 2002 4:30 pm, Lars Gullik Bjønnes wrote:
> | (Am I right here? passing a KeyRelease event to
> | fl_XLookupString((XKeyEvent *)xev, ..., &keysym, ...)
> | is pointless?)
>
> no...
Good. Then do_keyboard is right in this regard.
> | However, fl_handle_form does NOT process FL_KEYRELEASE. Ie, it just falls
> | through the routine. It is NOT passed to the FL_OBJECT handler.
>
> bad bad bad.
>
> | Shall I pass this analysis on to the xforms list? I'm in danger of making
> | a nuisance of myself ;-)
>
> I have reported this before...
> (but not in this detail)
I'll do so then.
> It should be possible to write an "xev" in XForms...
Indeed ;-)
Below is a summary of what I think xforms does wrong when handling key
events, together with my proposals to fix the problems. I've tried to explain
the main problem quite carefully. Could you read through them all and tell me
if you think I'm heading in the right direction.
Regards,
Angus
=========================================================
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) ?
Angus
