Fabien Costantini wrote: >> What is the normal use of a FL_NORMAL_BUTTON from a user's view? > ./.. >> Typing the shortcut is like clicking the button (pressing >> _and_ releasing the mouse button). The keyup events should be ignored >> (as they are for almost all other widgets in FLTK). > Agree in the' case of a normal button with a when() excluding the > FL_WHEN_CHANGED flag. > I agree that this default behavior should also be that the callback is called > when the button is pushed ; when we don't have the FL_WHEN_CHANGED flag this > is how it is done in Win32 and makes sense for shortcuts efficiency of use. > > But here's where my opinion still _really_ differs from yours: > IMHO, it is really important to handle both events (key push and released) > exactly as for the mouse when user specify to use FL_WHEN_CHANGED option.
I won't insist on my opinion, but I still think that this could also be a case for subclassing. We don't need to support all odd button features with a Fast and Light Tool Kit (FLTK). However, I'd really appreciate other developers' opinions. > Here's one reason I quickly have in mind that will stronger this opinion: > FL_WHEN_CHANGED should be *useful as is* especially when used in the fluid > Fl_Choice 'When:' menu (otherwise it would just generate a bug in the user > application who will not understand why it does not work as expected. Please > check out the current 'When:' options in the fluid properties interface when > using a button to clarify what I mean here. Well, that doesn't count. ;-) If we need it, we can extend the menu or change it to an array of toggle buttons for each bit, can't we? > This comfort me in the belief that this event should mimic the mouse event in > that case (but _only_ in that case, by opposition of when FL_WHEN_CHANGED is > not specified like for normal buttons use) > This will make meaningful what has no meaning today for the button concerning > the 'When:' FL_WHEN_CHANGED option and would be so simpler to use. > > Finally the semantics of FL_WHEN_CHANGED should really be : > "when any state changed", which is more general than "when released" and > should include it. My biggest problem with this is that it is _very_ difficult to handle the events *correctly*. Let me explain some points: 1) As discussed recently, a user may have to press more than one key (CTRL+X, ALT+X, or CTRL+ALT+X) to trigger a FL_SHORTCUT event (try yourself and add an Fl_Input, give the focus to it, and see). Now, after getting the shortcut event, all the keys are down (the sequence of pressing doesn't really matter). That's the easy part. But then the user can release _any_ key, and you must get the FL_KEYUP event, check it, if it was one of the shortcut keys (in fact, if this key and all the other still pressed keys together would form the shortcut combination?). I think that the proposed patch wouldn't do that correctly, but you did more testing and probably enhanced it already. And what, if a user types another key before releasing one of the shortcut keys? Example (tested with the proposed patch), type: ALT/down, A/down, B/down, then release any key... 2) FL_KEYUP events are not handled by default in any FLTK widget (checked only in the src directory). That means that every widget can receive FL_KEYUP events, independent of keyboard focus (yes, beleive it or try it yourself). What happens, if another widget catches the FL_KEYBOARD event, and the button gets the related FL_KEYUP event? 3) I think that using "value(oldval);" (FL_KEYUP case in the proposed patch) is at least _suspect_. But if you can solve all these issues, and if others also think that it should be done, well, then feel free to do it ... > I believe Greg initiated a similar discussion not so long ago. Yes, I thought so, too, but it was different: The case was that one defined when() condition (FL_WHEN_ENTER_KEY_ALWAYS) "implicitly sets the FL_WHEN_NOT_CHANGED bit", see STR 2094. Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
