>> * the filters have slightly different syntax ("type (*.ext)\t" vs.
>> "type\t*.ext\n")
I think I can support syntax invisibly.
I can just ignore matching open/close parens when specified
to support the FLTK's syntax, and change the docs to show
FLTK's syntax, and documenting the old spec as legacy.
> Yes, I always wondered that in particular, even though I like Native's
> syntax better. It would be nice to have identical APIs.
I admit I don't think I understood the syntactic purpose
of the parens in FLTK's filter specification, so I left them out
during the Native chooser design stage, and that survived.
Can be fixed easily though, I think.
> * filename() is indexed from 0 instead of 1
Guess I wasn't aware Fl_File_Chooser's value(int) method
was 1 based.
To be honest, I wasn't very familiar with Fl_File_Chooser,
and probably just went by the docs.
AFAIK, to date the docs don't indicate value(int) is 1 based,
so I'm sure that's why I missed it:
http://fltk.org/documentation.php/doc-1.1/Fl_File_Chooser.html#Fl_File_Chooser.value
I guess the good news here is the native chooser doesn't have any
value() methods, so since I have to add them anyway for compatibility,
value(int) can be 1 based.
Also, I can safely obsolete Native's filename(int) method, since there's
no equivalent in FLTK anyway. So I can leave that method in the widget
code,
and obsolete it in the docs as legacy.
So this works out well; old code will continue to work unmodified,
new code can use value().
But ick, I hate 1 based arrays; they're inconsistent with C++
arrays and vectors, and heck, computers in general. 1 base only
seems useful if there's a compelling reason to overload index 0.
_______________________________________________
fltk mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk
