[CORRECTION]:
On 03/11/12 11:43, Greg Ercolano wrote:
> So for instance, today [*if*] one of us had a version of just Fl_Widget
> that entirely uses Cairo, we could include it in the FLTK 1.x
> source as e.g. Fl2_Widget....
..emphasis on 'if'.
And I don't know what to name the parallel API..
Fl_Cairo_Widget, Fl_Cairo_Button, etc. or maybe
Fl::Cairo_Widget, Fl::Cairo_Button, etc.
Doesn't matter to me what the naming is, as long as
the evolving new widget set would be part of FLTK 1.x,
and not a separate fork.
Redesigning widgets to make use of Cairo could use
floating point, could be designed to auto-resize when
font sizes or window sizes are changed, or if all the
label strings are changed (due to the app running in
a localized language)
Perhaps too, we could address the issue of internationalization
by implementing a clever way to uniquely identify widgets.
I myself always liked the "pathnames" we use in Fl_Menu_Bar,
which could probably extended into the entire widget interface.
This way language files could redefine the entire interface
of an application, and the app could use these 'pathnames'
to refer to the widgets even if the widget's labels were
completely relabeled in another language.
So for instance:
Fl2_Window win(..)
win.action_name("appwin");
Fl2_Group grp(..)
grp.action_name("controls");
..
Fl2_Button but(.., "Update");
grp.end();
win.end();
..with this, "/appwin/controls/Update" would uniquely identify
the 'Update' button, so that even if the Update button's
"display name" were later changed by a language file to
be called something else, internally that pathname would
still work to identify the button, and the button could
also determine its own name by walking up the widget hierarchy,
just like a file system.
I imagine the big problem with all of this, though, is we
don't have a key developer who has the time and ability
to both envision and implement all this stuff. Lately the
devs have apparently been so busy, few have had time to
put large amounts of time and thought into this.
_______________________________________________
fltk-dev mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-dev
