On 15.12.2010 17:07, Greg Ercolano wrote:
>> If it's easy for you to incorporate an option (IIRC you mentioned that
>> this would only be a few lines of code), then I wouldn't object to
>> add an option in FLTK 1.3...
>
> Yes; the change in Fl_Input is tiny for adding that.
>
> However, the changes for removing the emacs stuff is a bit of work;
> about 100 or so lines of code had to be touched, as internally
> Fl_Input translates most non-emacs codes into emacs first. eg:
...
> Had to change this to private methods for the separate
> key operations, which is a bit cleaner:
...
> Once you start down that road, you have to do them all
> for consistency.
>
> I made the methods 'private' so that we don't change the
> public api.
Hmm, maybe protected would be useful (but then we must document
them, too). Oh, and maybe also virtual...
<brainstorming on>
Then we could have a method like handle_tab() that returns true
or false, and you could override it in a derived class, and then
we wouldn't need an option for handling the tab character globally.
Well, this would only work for derived classes...
But while I'm thinking about it: what keeps us from adding a method
to set a flag to Fl_[Multiline_]Input to change the tab behavior?
This way we can probably get the best of all:
- no need for a /global/ option
- compatibility with older software (default)
- optional per-widget change to use TAB for navigation
- still being able to use ^I for TAB internally
- the "new generation Fl_Multiline_Input" widget (Fl_Text_Editor)
won't be affected and will use TAB always internally
<brainstorming off>
Any comments?
Albrecht
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
