I am not sure how styles changed in fltk 2 recently so forgive me if I am not completely accurate. There are a few things in f2 styling I did not like too much:
1) The styles tree follow closely the classes inheritance tree. However the widgets programatical inheritance do not match well appearance similarity (style parents inheritance) so you end up with lot of "default" styles and re-definition of values and appearance; inheritance becomes complicated, could be quite misleading and misses the point of having few places to control the properties. 2) because the value "0" means "inherit value from parent" and the chain of parents can be quite long, multiple recursive dereferencing(value digging) together with "if" condition can have some influence on performance. If the main advantage of styling is just to save some widget space then I do not thing its worth the effort. However I can see the advantage of single point of control of appearance. Another possibility - simpler, closer to fltk 1.x - would be setting & control of some global style rules: The constructor(s) of the widget(s) would just copy current values from these rules at the time of widget creation. User could control that at run time by swapping the values within these rules. This would not allow for later change but to be honest changes of properties (like font sizes) might need much more maintenance (eg font size migh require change of placement and/or size the widgets etc) than just change of a value within a style. R. On 28/08/2011 22:14, Matthias Melcher wrote: > > I am starting to port a very convenient and extremely space saving feature > from FLTK 2 named Styles. > > Even though FLTK Widgets are generally lightweight, the still haul a bunch of > redundant information around. Every widget has an entry for its label font, > color, size, box type, etc. etc. . Most of the time, these values are the > same in an entire application. The font color in Fluid, for example, is > pretty much always black. > > FLTK3 now provides a single default style that will carry all those > attributes. Every new widget will link to that style, instead of repeating > the values over and over. Of course, you can change the default style. By > changing the font size in the default style, you change the default font size > throughout the application. That can be very neat. > > Now, you may have widgets that need, let's say, a red label instead of a > black one. No problem, just call "myWidget->labelcolor(RED);" and this one > widgets changes color by automatically generating a private Style class. All > other attributes btw. still "shine through", meaning that this label still > uses the default label size. Unless of course you change that too, using > "myWidget->labelsize(10);". > > Of course, widgets can share styles, so you can have a number of widgets with > a green label, and a number of widgets with a red label. You can build an > entire hierarchy of styles with branches that change only one or many or all > attributes. > > Going further, there will be default styles for individual widget types. This > way, a user can change the box type of all sliders from down to up, or > whichever other attribute. This opens up another huge door: now a Theme > interface simply changes a few default styles around as needed, and voila, we > quickly generated a new theme. > > Now for the cost: I am using a caching scheme to avoid climbing up the style > hierarchy every time I need a single attribute. So performance wise, we have > one more indirection - that's all (if I remember correctly, that would be "O" > instead of "n x O"). In respect to RAM use, Styles should use much less > memory than the old system! Yay! The Widget API btw. stays the same. All the > widget->labelfont calls are still there and still work just as expected, only > there is more smarts under the hood. > > Lastly, here is a sample program (which I have not tested ;-) > _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
