On 12.10.2010, at 18:28, Greg Ercolano wrote: [long story and example code removed]
> With this, if the user forgets to click in the password field, > and just types 'sally', the 's' triggers the machine to start, > and the 'a' triggers the machine to stop. > > I'd posit this is unexpected and probably bad behavior. > I'd think a modifier like Alt (for win/linux) > or Cloverleaf- (for Mac) would at least be needed, similar > to how menubars work. > > If the programmer really wanted unadorned letter shortcuts > to work, they could use shortcut() to define the exact sequence, > or derive a widget that handle()ed multiple keypresses if desired. That can be done by _not_ defining a label shortcut and doing what you suggested. But if you define a label shortcut, ... (see below). I added more comments to STR #2243 here: <http://www.fltk.org/str.php?L2243> > Or maybe we should have a compatibility flag that enables the > current behavior, but have it disabled by default. I hope we can avoid this. I vote for *one* solution. > Just fishing for some thoughts on this. Thanks for bringing this up here. > Currently the docs for Fl_Button (under 'Description') says this: > > Buttons can also generate callbacks in response to FL_SHORTCUT events. > The button can either have an explicit shortcut() value > *or a letter shortcut can be indicated in the label() with an '&' character* > before it. For the label shortcut *it does not matter if Alt is held down,* > but *if you have an input field in the same window*, the user will have to > *hold down the Alt key* so that the input field does not eat the event first > as an FL_KEYBOARD event. > > I don't think we currently hold to that last sentence, as it seems > if there's an input field in the same interface, still regular > letter buttons will trigger the shortcuts. You're right if you read the text literally - however, I think that it meant something like "... but *if you have an input field in the same window*" add here: "... that has the focus". If we add this little omission, then the text and its intention becomes clear: Label shortcuts can be triggered no matter what additional modifiers are pressed or not, as opposed to explicit shortcuts. This doesn't say anything about menu bars though, but that's IMHO a special case. I vote for keeping this documented behavior and applying the (maybe slightly modified) patch from STR #2243 to achieve the "menubar only with ALT" behavior. This way we wouldn't break existing apps that rely an the old label shortcut behavior. More comments welcome... Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
