Fabien Costantini wrote: > [STR New] > > Link: http://www.fltk.org/str.php?L2026 > Version: 1.3-current
I am posting this to fltk.development for discussion to keep the STR free from too much discussion. We should add a summary when we are finished. > Now for the pertinence of this STR, > I believe that FL_WHEN_CHANGED should handle all important changes when > the keyboard is used as when the mouse is used, > otherwise we have a serious nonorthogonality problem here. > If the mouse changes the button state when released on a button then the > keyboard should change it as well. > IMHO, the documentation confirms this problem and should be updated as > well when this coherency problem is fixed. > It may make our life more complicated but this is what we should do IMHO. IMHO, the shortcut and the mouse events are completely different, and they should be handled differently. The way I read the documentation means that handling shortcuts for a button is completely independent from (orthogonal to) handling mouse events. What is the normal use of a FL_NORMAL_BUTTON from a user's view? Clicking the button "does something", starts an action etc.. The normal behavior is that this happens when the mouse button is released. Adding a shortcut means that you can "click" the button by pressing a key combination, e.g. ALT+X for e&xit, but then the action will be started when the key combination (the second key) is pressed (not when released). 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). > Also, I believe that a normal button has two transient states 1 then 0, > and that it is really interesting to know in what state we are, when we > use it as a two states button (thanks to the when() condition set to > FL_WHEN_CHANGED (ideally without the FL_WHEN_RELEASE OR'ed IMHO)) > It an easy to determine in the callback if we are pushed or released. I agree that a button has two transient states, but IMHO using a FL_NORMAL_BUTTON as a two state button is a border case, anyway. IIRC, we can't guarantee that a mouse button release will always follow after a push, because dragging the mouse, and then releasing (over another window, maybe), or pressing ESC may act differently (not sure about this, however). > For the clarity of the discussion, > Imagine for example a midi keyboard application where we would like to > simply associate a midi note event (note on or off) according to a key > shortcut pressed or released. > In such application, I believe it would be highly desirable to have the > midi callback called twice whatever it was originated by the mouse push > and release or by a keyboard key pressed and release. > A natural way I would think of first would be to USE FL_WHEN_CHANGED for > that and that it would work transparently for both mouse and keyboard. I wouldn't even think of using button widgets for this type of application. Remember that we're talking of buttons and shortcuts (ALT+Key, in the general case, i.e. if some other widget has input focus). But if you really want to do this _special_ coding with Fl_Button widgets, then you really should derive your own class and write your own handle() method. So, what should be done? (my opinion): 1) Make the when() documentation more explicit about the conditions, but leave it as it is (as I understand it). 2) Close the STR, because the desired behavior can be achieved by setting the appropriate when() condition (FL_WHEN_CHANGED|FL_WHEN_RELEASED). 3) The more combinations of events we want to support, the more complicated and error-prone becomes our code. Keeping things simple (one bit for one action) keeps the code Fast, Light and hopefully stable. 4) Don't try to support all combinations of interactions with the normal FLTK callback method. Special casing is subject to deriving one's own class. > Not sure I'm clear (!) , The same here ;-) What about other developers' opinions? BTW.: I think that we are missing parts of the old when() documentations (e.g. Fl_Input_) in the new FLTK 1.3 docs. I'll have to check this, and maybe write an STR. The same problem exists probably with type(). Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
