On 04/27/12 17:07, Fabien Costantini wrote:
> Link: http://www.fltk.org/str.php?L2828
> Version: 1.3-current
>
> something really [nice] to do to do would be to sync the item default bkgnd
> color to the box color instead of white, thus not making the assumption
> that the default bckgnd is white...
> More precisely what could be done is make sure that first item creation
> use a lazy/late binding scheme that would ensure that an item (i.e. the
> root) would be created only after the default color has been set ?
OK, I'm about to commit this as an ABI feature.
The way it works, when draw()ing the items:
o Use the item's labelbgcolor() IF IT HAS BEEN SET. Otherwise..
o Use the tree's item_labelbgcolor() IF IT HAS BEEN SET.
Otherwise..
o Use the tree's Fl_Tree::color()
A similar technique is used for the foreground colors.
Changing the global colors will affect how the whole tree is drawn
(unless the higher level colors are masking it).
This behavior is implemented with bitflags at each level,
similar to how an alpha channel behaves. The management
of the bitflags is transparent to the app; it's all handled
internally.
Once a color has been set, it 'masks' the use of the more global
colors. The default behavior can be restored by calling methods
with the "reset_" prefix, ie. "reset_item_labelbgcolor()" will restore
default behavior if the app had set a color with "item_labelbgcolor()".
_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
