On 11.10.2011 01:14, Richard Sanders wrote: > > > On Mon, Oct 10, 2011 at 1:19 AM, Albrecht Schlosser wrote:
(citation trimmed...) > Okay, I tested with and w/o the patch with the new attached spinner2.cxx > that has another button (label NOP) just to receive input focus when > pressing the TAB key, or to click on it to move the input focus from the > spinner input field to another widget. > > (1) TAB works as expected and triggers the callback w/o the patch, > as well > as clicking on the button (FL_WHEN_RELEASE works as expected). > > (2) *With* the patch, each key press in the input field triggers the > callback (as expected with FL_WHEN_CHANGED), but this is /not/ the > *intended* behavior of this widget. > > Thus, this STR should be closed "w/o resolution". > > To Richard: if you /really/ need the behavior as changed by your patch, > then you should write your own widget, since we can't change it as > suggested in your patch. But maybe this was only a misunderstanding? > > Note that my test was on Windows, maybe you see different behavior on > another platform? Please comment on this, otherwise this STR will be > closed w/o resolution in a few days. > > > Link: http://www.fltk.org/str.php?L2729 > Version: 1.3-current > > > As Fl_Spinner stands our of the box. The callback gets executed every > time that the value is changed via the up down buttons. To \not\ have > the callback done when the value is changed via the keyboard is > inconsistent behavior. Consistent behavior would be > 1) Never call the callback on a value change. > 2) Always call the callback on value change. Hmm, I really don't understand what you are saying here. As it is currently, the callback *is* called when the user changes the input field, but only after "saying that he is ready" by pressing the Enter or Tab key or clicking on another widget (losing focus). This is exactly what I would expect from such a widget. Imagine the contents of the input field is 31, and the user wants to change it to 32. The first keypress would probably delete the 2, and now the value is 3. With your patch, the callback would be called now, although the user is not ready with editing the value. Then the user would hit the 2 on his keyboard, giving the value 32. Now the callback would be called again (okay this time). But now imagine that the user would have hit the 5 instead of 2 ... More and more callbacks for each key press. Although this might be interesting for some low-level stuff, I'm sure that this is not what /most/ developers would expect of such a widget. > Really consistent would be to have the callback for Fl_Spinner executed > in accordance with the when() of Fl_Spinner and not the when() of the > internal Fl_Input. This is something different, and it's worth a consideration. If you like to have this, then you should probably add an STR (with RFE status) for 1.3-feature to request such a finer control over the widget. This might be feasible... > And that is the real problem, my suggestion is a > kludge that makes it appear uniform to the user. For a programmer to > have to instruct the user to only change values of Fl_Spinner via the > up/down buttons makes the programmer look like an idiot, the programmer > following the trail looks at the library provider and says....... That's not the case! Please see above. > I presume the intended behavior of Fl_Spinner is to allow the programmer > to specify the callback but have no control of the when(), as is the > case currently.I do not want to appear nasty or ungrateful but > Fl_Spinner seems to be more of a proof of concept rather than a finished > item. That may be correct, IIRC it was added somewhere during the 1.1.x life time, but maybe as a quick "hack" (all code is in the header file). It looks as if it was added (in svn r4149) for printing support in fluid (r4150). Anyway, IMHO it works as designed (as far as keyboard input is concerned). I'd like to read other opinions, though. Devs, please? > Fl_Spinner has the same behavior in Windows and Linux. Thanks. Albrecht _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
