From what worked in FLTK2, I don't think we want or need per-class styles.
All customization I have seen involved changing the Widget style (the base class) and the 2 or 3 per-class ones who's only reason for existence was that the default values were different. I suggest this be fixed by making more fields in the base class so all widgets can share the same one. It really is not very useful to change all the numeric text editors to a different color. What users want is to change *all* the text fields to a different color. As FLTK1/2 are designed these do not come off a common base class, so it was much better to put the field in the Widget base. Other than colors, almost all the rest of desired customization involves changing the graphics drawn for buttons and scrollbars. FLTK1/2's attempt to do this with the box types did not really work well, as it would tend to replace only part of an FLTK application. I think a better approach would be to have a function the user can replace that takes the box type (which remains an integer) as an argument. For back-compatibility there will be a bunch of redundant box types (thin, thick, shiny, etc) but any new theme can just treat these all identically. Maybe shiny can be eliminated as it really is a theme. It would be VERY useful to get some information on the GTK theming api, the KDE theming api, and on the Windows Appearance api. Any new design HAS to be able to call these, so if the fields don't match then it is going to be difficult! _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
