> I don't think you can use the arrow keys for shortcuts, because they > tend to get eaten up by other widgets first, e.g. any sort of text > widget that gets the focus will swallow any arrow keys it sees, for text > navigation, and at a higher level, arrow keys get eaten by widget > navigation... > > Maybe, if you had no text widgets, and you used clear_visible_focus() to > disable keyboard widget navigation, then the arrow keys *might* become > available for use as shortcut keys... But that's mainly just > speculation.
I got this effect by having the window's handle() only pass on FL_PUSH and FL_MOVE and then overriding FL_Input's handle to throw focus to the window when it loses it, instead of casting about for someone else to give it to. The event handler in the window then gets all events except drags captured by someone who wants them and keys when an input has focus with no pesky keyboard navigation. Seems to be working so far. 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". 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! I wound up poring over src/Fl.cxx quite a bit before I figured out what was going on, and I've already forgotten the details. 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. As another aside, I noticed in the source that delivering KEYUPs to the widget that just lost focus was considered the right thing to do, but too hard, so I wound up having to keep a keydown map to filter those out myself. It didn't seem too hard to me, but then I have the STL. Would it break people's code in subtle ways if a future version of fltk didn't "split" keydown/keyup pairs across the loser and getter of focus? _______________________________________________ fltk mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk
