Albrecht Schlosser wrote:
>> 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...
We could always open them up.
I just didn't want to get into an 11th hour API design session ;)
Note that there are existing public API cursor and edit functions
(like position(), mark(), cut(), copy(), etc) which should be
sufficient.
The edit functions I've added are merely shortcuts with
code specifics the event handler needs.
But if we look at the result and decide to make em public,
that should be easy.
> 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...
Interesting.
I figure the global option would be the most useful though;
it seems like something that works best if it's consistently
set across the entire app. And it'd be the odd case where the
app programmer wants one multiline to act differently.
I imagine the best situation is a combo of a global setting
with per-widget controls to override the global setting,
similar to what we now have for the global Fl::scrollbar_size(),
and per-widget settings with <AnyWidget>::scrollbar_size().
This way one could control global, individual, or combos.
> 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?
That would certainly be the easiest thing to add.
Note this is /only/ an issue for Fl_Multiline_Input.
Fl_Input and friends don't have this issue; Tab operates
'normally' in those.
Only Fl_Multiline_Input is the odd one of the bunch
that by default interprets tabs like a text editor.
> - 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
See above sugg regarding a global with per-widget control
vis a vis Fl::scrollbar_size()
But I'm fine either way, as long as there's "some" way to
get "normal" focus nav behavior, which I don't think we have
currently via the public API. (Other than deriving a new class
with a handle() method that passes tabs through.)
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
