Evan Laforge wrote:
> As an aside, when I was trying to figure out how FLTK event delivery
> worked, I found it galling that the documentation had the nerve to
> describe it as "simple".
Those docs may mean "creating an event handler" is simple.
How events flow through apps is somewhat complex, certainly,
which is the case in any environment.
Before one decides whether "it should be simpler" you have to
consider the behavior of standard widgets, like what should happen
if an Fl_Multiline_Input is one of the widgets in the app; should a
global up/down arrow shortcut usurp Fl_Multiline_Input's handling
of that key, even if that widget is 'in focus'? Probably not..
Also some events cause others which are mode oriented, like
clicking on a widget changes focus around, etc. All standard
behaviors where event delivery order gets tricky and specific.
> Events go to parents -> children, except depending on where focus is,
> some go directly to children, and except
> FL_SHORTCUTs which go child->parent (sending it to random neighbors
> too), and then there's this global event handler which is actually a
> list of handlers, and the button-down widget is sort of like focus for
> the mouse but slightly different somehow (I think?), and then shortcut
> delivery can depend on the mouseover widget... this is not what I
> would call simple!
At least your description fit into a single paragraph. ;)
Such a description would be a great thing to have in the docs,
if indeed no such thing exists currently. Key/mouse event flow
vs. window event flow (enter/leave/focus) should probably each
have separate descriptions, as well as how certain kinds of events
can modify event flow (such as how clicking on a widget can
affect focus).
So that would be a good STR against the docs. The event
delivery mechanism is probably stable enough to where it
should be documented.
Especially since event flow is a concern not just for widget
programmers (who might expect to trawl the FLTK source),
but for app programmers as well (who should not).
> Would anyone else like "a way to override the global event handler" on
> the future-fltk wishlist? Of course that would just make things
> *more* complicated. Suggesting a simplification of the whole thing
> might be too radical, and probably some people like the current
> behaviour.
It's interesting if there isn't a way to globally intercept
events *before* events are sent to all widgets.
Probably the only one I know of offhand is via a 'grab'.
Seems it wouldn't be hard to add such a hook if one doesn't
exist.
The hook should surely have a "use at own risk" warning,
since if your app overrode 'up arrow', there'd be implications
if there was an Fl_Multiline_Input or Fl_Text_Editor widget
somewhere in the app; the user shouldn't get a surprise if
they hit up arrow to move the cursor, and get a button callback
invoked instead.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
