On 13.12.2010, at 22:25, Greg Ercolano wrote: > The behavior seems obsolete with the advent of Fl_Text_Editor. > (Arguably an app expecting Tab from users should use Fl_Text_Editor)
It's not the same, and Fl_Multiline_Input has both the advantage and drawback that it doesn't have scrollbars. This can sometimes be important (for instance if space is a concern). > Also, one can still access the Tab character via ^I. That's good, I didn't know this but discovered it when looking at the code. This should be kept no matter what we decide. > For vote: > > Modify Fl_Multiline_Input to use Tab for field nav, to be > consistent with all the other derived versions of this class. > (the ^I workaround for users would be documented) 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). But we should probably announce this change for 1.4, so that developers can educate their users. Another option would be to add another Fl::option, but I'd rather postpone the change to 1.4 and do it then unconditionally (without Fl::option). However, if you all feel that it's okay to risk that users will shout "My TAB key doesn't work anymore!", then I'll accept the decision. I know that /my/ users don't need it. ;-) Albrecht _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
