> > Personally I would say +1, but I believe that there may be *users*
> > that depend on this "Tab-in-Fl_Multiline_Input" feature, thus my
> > vote is
> >
> > -1 (for now, i.e. FLTK 1.3).
I see.
Curious how you feel about a global 'normal key nav' option
eg. Fl::normal_key_nav() which:
a) changes tab behavior
b) prevents left/right edit keys from accidentally key nav'ing
into other fields, so that only Tab/ShiftTab will shift fields
Both of these are very easy to implement in FMI;
One liner for (a), and (b) already exists as a macro that can
be changed to refer to the global option.
> -1 for the same reason. In future version, Fl_Multiline_Input should =
> become a wrapper for Fl_Text_Editor.=
I thought about this previously, and wonder if it will
ever be possible; doing that would break any app that
derives custom widgets from it which assumes Fl_Input/Fl_Input_
are underneath.
And any app wanting the Fl_Text_Editor-like behavior would
simply switch to using it, I think.
I'm thinking Fl_Multiline_Input would probably have to stay
a derivative of Fl_Input + friends as long as it remains
in FLTK..
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
