> > What I'm not sure about is what should happen if the app > > then changes color(); should new items use the color(), > > or should they stick to using the item_labelbgcolor()? > The answer to the question in the example would be cyan because color() and > item_labelbgcolor() would affect internally the same private [color] > attribute ... > Wait, I see your problem now as you want to keep the ability to have custom bg colors after user use the API.
So let me make an iteration on that and refine the proposal as follows: color() is the background color of the tree and is different from the item label bkgnd color. Now, at initialization the item label color is an 'undefined' value (let say 0xffffffff ?). Note that value would be stored in the prefs as well if user did not specify a custom color. When it would have this undefined special value, the Fl_Tree code would automatically substitute it dynamically to color(), when it has a valid Fl_Color value then the latter is taken in account (as it is now in the current code)... The advantage here is that the user can voluntarily set the label bg color back to the 'undefined' state at any time which would simply means that from now on it would rely on the color() fallback value. So to correct my previous answer, in that scenario : the label color would keep the BLUE value and the item bkgnd color of the next created item would be BLUE. Finally, that implies that you also keep separated the color and item_labelbg_color attributes and that is perfectly fine/valid IMHO in that scenario, again this differs from my previous answer that would initially not care about the extra feature you expose on item label colors. -Fab _______________________________________________ fltk-bugs mailing list [email protected] http://lists.easysw.com/mailman/listinfo/fltk-bugs
