> 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. 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. 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. I believe Greg initiated a similar discussion not so long ago. Fabien _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
