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.
_______________________________________________
fltk-bugs mailing list
fltk-bugs@easysw.com
http://lists.easysw.com/mailman/listinfo/fltk-bugs
