On 05/02/12 11:48, Greg Ercolano wrote:
> 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 ?
Fabien: one question about implementing this.
I take it you want the color() to be the default for
newly created items.
But since we have tree->item_labelbgcolor() that's supposed
to affect the newly created item's color, I'm wondering how
color() and item_labelbgcolor() should interact.
Currently newly created items by default inherit the
tree->item_labelbgcolor().
I can change the behavior so that if tree->item_labelbgcolor()
is left unset, color() will be used instead, and changes to
color() will be used, and that's fine.
Up until the point the app then sets tree->item_labelbgcolor(),
which would override using color(), and even that makes sense.
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()?
As an example of what I mean:
tree = new Fl_Tree(..);
tree->color(FL_RED);
tree->add("aaa"); // OK: "aaa" will be red
tree->color(FL_GREEN);
tree->add("bbb"); // OK: "bbb" will be green
("aaa" remains red)
tree->item_labelbgcolor(FL_BLUE);
tree->add("ccc"); // OK: "ccc" will be blue (bbb
and aaa remain their colors)
tree->color(FL_CYAN);
tree->add("ddd"); // ???: will "ddd" be (1) blue
or (2) cyan?
_______________________________________________
fltk-bugs mailing list
[email protected]
http://lists.easysw.com/mailman/listinfo/fltk-bugs
