On Wed, Apr 2, 2008 at 12:05 PM, Greg Ercolano <[EMAIL PROTECTED]> wrote: > 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.
Here's the sentence: "FLTK follows very simple and unchangeable rules for sending events." "Very" simple no less, that's what really got my goat :) Anyway, documentation for all event shennanigans does exist, scattered about on that page, but it would be nice to have it right there in the "Event Propagation" section. Matthias's description was clear and concise, something like that would be nice. > 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.. Right, hence the "some people like it" part. My app happens to not use complicated focus or tabs so I don't mind. But anyway, my scheme still works for multiline, because keyboard events still go directly to the focused widget. I can't change that without modifying the fltk source anyway. In general though, I like to keep modality under control in GUI apps, which means none of that keyboard navigation stuff that focuses on buttons and whatever else (of course focusing on a text input is necessary). Use of local event handling seems to be generally bad for consistent app behaviour, to me. It's just personal philosophy though. > 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. Yeah, hence my desire to turn all that off in favor of my simpler scheme. While a widget toolkit may legitimately push a particular philosophy (e.g. complicated modal focus), I think it should at least provide a non-hacky way to opt-out. > 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). I think one of the strengths of fltk is that when you inevitably go trawl the source at least there are few enough layers that you can understand it. The fact that you often have to is a bit of a downside though. > 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. Yeah, at least some advice to deliver to the focused widget if you want text entry to work right, and pass FL_PUSH down the chain if you want drags to work right. I actually think the "global" event handler should be per window, so you don't automatically destroy all reuseability by using it. Really, I originally expected that fltk would put all events parent->child through the window's handle, and that FL_Group would pass it to a focused child if there were one. Then you can remove FL_SHORTCUT and if you really want children to override parents key commands, have FL_Group pass to children even if it recognizes a shortcut. If there are no objections, I can add STRs for the docs and a way to intercept events before they head off to the focussed widget or whatever. _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
