On 01.09.2011, at 00:16, Roman Kantor wrote: > 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.
FLTK2 has a default style for every class. I don't think we need that. One common "super" style plus five or so styles for basic widget type should be enough. Everything else is optional. > 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. In FLTK3, an extra flag tells us if the style overrides the parent style or not. There is no value digging. All values are cached in the style that is directly connected to the widget. Only if a parent style is changed, the widget must dig once for the setting and then caches it again. > 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. The second. Imagine Fluid: it has input fields for code (monospaced font (i.e. widget class), and input fields for text (cursive font (i.e. tooltips)). We can set all attribute in two styles and never bother setting a textfont again. > 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. That would be the advantage of issue 2 (styles) combined with the disadvantage of 1 (needing a lot of space). _______________________________________________ fltk-dev mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-dev
