> 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).
Interesting; if one were able to disable the scrollbars
in Fl_Text_Editor (FTE), then Fl_Multiline_Input (FMI)
could just be a wrapper around FTE.. many problems solved ;)
But legacy this; existing apps expecting Fl_Input/Fl_Input_
underneath would be broken by such a change.
I wonder if somehow the engine beneath Fl_Text_Editor
could somehow drive all the above. That'd probably be
a lot of work though, since the existing API probably
wouldn't fit.
Regarding scrollbars, I think FLTK stands alone in the world
with its multiline input without scrollbars. Even in a
space constrained app, I don't think it can possibly be
desirable that scrollbars don't appear.
> -1 (for now, i.e. FLTK 1.3).
OK. How about a global option (Fl::normal_keynav(0|1))
that changes Fl_Multiline_Input's behavior so that Tab
is ignored.
This would at least allow what might be a majority of apps
to be able to have a multiline input field that behaves
like the rest of the world.
We should maybe also have the current NORMAL_INPUT_MOVE
macro replaced with this same global setting, so that
the app can prevent key nav off input fields with keys
other than Tab.
I know that almost every app I write would want to turn
that global flag on in main() right up front ;)
> But we should probably announce this change for 1.4, so that
> developers can educate their users.
Sure, sounds good.
> 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).
Actually, I think you'll find the need for both. Some FLTK apps
really need the 'old' behavior (eg. in the case of arrows acting
as key nav, for tools like spreadsheets and navigating complex
input forms where arrow keys are the only way that makes sense.
I think anything called FLTK 1.x has to support those wacky
old behaviors.. the only way to get away from it would really
be a 2.x or a 3.x.
I'd like to suggest we do the Fl::xxx() option approach sooner
rather than later. For sure it's a one line change in Fl_Input
to solve the Tab behavior.
Also, for the arrow key nav behavior, that's just a matter of
changing the NORMAL_INPUT_MOVE macro to be look at the option
instead. (In my changes to Fl_Input, I was able to make sure that
macro worked properly for all modifiers, testing with the flag
on and off)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
