I see there is the start of a "Style" structure in fltk 3.0 I think fltk2 made some mistakes which should be corrected, but it mostly worked.
The main mistake is that fltk must work with every single widget sharing a single instance of Style. This allows every widget to see everything else about the setup, and also makes it trivial to load a "Style" from a file, rather than having to invent some meta-object which is a "set of Styles". This means that if two different widgets, by default, need different colors for some purpose, than there has to be two fields in the style for this. Buttons and text fields cannot share the same color. This should be easier in fltk3 because there is no need to map any fltk1 names 1:1 with style fields. A very serious investigation of the "style" apis used by Windows, GTK, and Qt is needed. There is a strong desire to call GTK styles (even Qt was modified to do this), and I suspect almost as strong a desire to make fltk work with the Windows Appearance Manager. Thus it should be possible for a significant portion of these to be called by a style. _______________________________________________ fltk-dev mailing list fltk-dev@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-dev
