> >> On 05/08/12 19:47, Fabien Costantini wrote: > >>> 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. > >> > >> Ah, OK, I was going to use a bitflag to keep track of this, > >> and a special 'reset' method to control the flag, but overloading > >> the color ff/ff/ff/ff is better. > > > OK, try r9478. > > It defaults the item_labelbgcolor() to 0xffffffff. > > The interpretation of this is entirely in the draw() code; > the set/get methods are consistent in how that value is returned. > > This way the user can test for that value to see if 'transparent mode' > is enabled. Also, if the user changes it to a 'normal' color, they > can set it back again to 'transparent' mode. > > The docs cover this behavior, and it should be backwards compatible > in that the tree's behavior should be consistent with previous versions. > > I've enhanced the test/tree application to test for this; > click on the "Test Suggestions" button at the lower right to see how > to test this new color behavior (under the 'Color' section). > I had a quick look and built the latest trunk, that looks really fine ... good job Greg!
While I was there, I noted that fluid does not show yet a selected tree item in the WYSIWYG preview of the Fl_Tree, maybe it would be nice to have one or more item(s) selected so that the user could instantly check his color2() setting ? _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
