> 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. > > It's interesting: I had thought all bits were used in Fl_Color, > and they sort of are, but indeed there are many patterns of > bits that are simply 'undefined', ff/ff/ff/ff being one of them. > (ie RGB bits AND colormap bits all enabled). > > So I could document that the special color ff/ff/ff/ff is 'see through', > so that if the item's bg color is set to that, the item's background > won't be drawn at all, causing the underlying color() of the widget > to show through. > > And this would be backwards compatible with existing code, > because that bit pattern is normally 'not allowed'. > > Sounds good, I'll go with that. Note also that that this design choice has another interesting property that is that it preserves the knowledge of the default bckgnd color (what you call see-thru) for the item created, which means that if the user decides to implement a blinking tree background, it is really going to behave as expected intuitively (items with custom colors will keep their colors but the other items would 'follow' the default background colors even when it changes AKA color(newColor) is used) with no need to replace the color in all previously created items.
Also note that that in the particular case of the user asking the item_labelbgcolor() when it has not been set with a custom color yet ; user should get this 'undefined' value and it should be documented that way. Because it would not make sense IMHO to return the color() color in that particular case, as there would be no way for the user to keep track/knowledge that the color() was the undefined one, at least not easily. More precisely, if user wants to save/restore the current item label bg color, we should care about the side effects and make sure we return the 'undefined' value even if it means that user must implement special code to finally figure out what is currently the real color value ... _______________________________________________ fltk-bugs mailing list fltk-bugs@easysw.com http://lists.easysw.com/mailman/listinfo/fltk-bugs
