Albrecht Schlosser wrote:
>> Fl::option(OPTION_ARROW_FOCUS)
>
> Yes, this is already there, but I was surprised that I discovered
> recently that the old macro NORMAL_INPUT_MOVE was still in use in
> Fl_Input.cxx and Fl_Text_Editor.cxx.
>
> Greg, I fixed these by removing the obsolete and unused macro from
> Fl_Text_Editor and by redefining it to use Fl::option(..) with some
> comments that should make the values clear. I hope that this doesn't
> break anything in your current work, but you might consider to change
> this as you need for the input key handling. Thanks for your work on
> changing the key bindings!
Sounds good -- that's a welcome modification.
I see your redefinition of NORMAL_INPUT_MOVE and merged it in
to my offline stuff.
> 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:
--------------------------------------------------------------------
case FL_Delete: // Delete key?
if ( <no-modifiers> ) {
ascii = ctrl('D'); // convert to emacs delete
} else if ( <shift> ) {
ascii = ctrl('X'); // convert to emacs cut
} ..
..
switch (ascii) {
case ctrl('D'):
..do delete..
case ctrl('X')
..do copy/cut..
--------------------------------------------------------------------
Had to change this to private methods for the separate
key operations, which is a bit cleaner:
--------------------------------------------------------------------
int Fl_Input::delete_char_right_() {
..do delete..
}
int Fl_Input::copy_cut_() {
..do copy/cut..
}
..
case FL_Delete:
if ( <no-modifier> ) return delete_char_right_();
else if ( <shift> ) return copy_cut_();
..
case 'x':
if ( <ctrl> ) return copy_cut_();
..
--------------------------------------------------------------------
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.
>> there should maybe be an OPTION_STRICT_TAB_FOCUS (or some such)
>> > which would handle (a), but in our case, having the default be off
>> > for 1.3, with release notes indicating the default would be 'on'
>> > in a future 1.4 (as per Albrecht's suggestion in this thread).
>
> 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...
I'll save that for a separate commit, after the Fl_Input mods
are complete.
I see the Fl::options() thing has really taken off..
I haven't used Fl_Preferences yet, but I see the options()
are all tied into that.. neat!
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
