DO NOT REPLY TO THIS MESSAGE. INSTEAD, POST ANY RESPONSES TO THE LINK BELOW.
[STR New] Link: http://www.fltk.org/str.php?L2828 Version: 1.3-current @Fabien: Yes, indeed, there was an intention to do this when I designed the API. The intention was to have it similar to the way the global scrollbar size stuff works, where one control the scrollbar size globally in an application, but also give individual control when needed that overrides the global behavior. Fl_Tree::item_labelfgcolor() and Fl_Tree::item_labelbgcolor() are supposed to allow you to change the entire tree's fg/bg color even /after/ the tree has been built. The only time an item's own color would be used is if it were first SET by the app. So I imagined I could use a bitflag to indicate whether a color had been set or not. Apparently didn't get around to doing that. So I think I can add bitflags for this.. I imagine it can work this way: o If the app doesn't try to set Fl_Tree::item_labelfgcolor()/bg and doesn't try to set a specific item's fg/bg color, the widget's own color() and labelcolor() will be used for all the items. Changing the color()/labelcolor() will affect the items globally, even /after/ the tree is built. o However, if the app sets the Fl_Tree::item_labelfgcolor()/bg, then this globally overrides the use of the widget's color() and labelcolor(). This way, the app can still globally control the tree's item colors even after the tree is built, while still allowing the widget color() and labelcolor() to be different. o Finally, if one sets a particular item's color, this will cause that item to be drawn in that color, overriding the above. Link: http://www.fltk.org/str.php?L2828 Version: 1.3-current _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
