Angus Leeming wrote:

> Abdelrazak Younes <[EMAIL PROTECTED]> writes:
>> > The patch looks good but I am wondering if this solution is not a bit
>> > too complicated. Why not just define some const string in hexa and let
>> > the frontend take care of the rest?

What would we gain? Not much IMHO. Whether a color name is given in
"#rrggbb" notation, or as a real name "linen", does not matter IMHO,
because in both cases the frontend will resolve it to an rgb value, and to
users of ColorEntry it is just a string.

>> Just for clarification, this would mean replacing x11name by this RGB
>> value in ColorEntry:
> 
>> class ColorEntry {
>> ColorEntry(
>> string rgb_hexa = "#000000",
>> string const guiname_ = "",
>> string const latexname_ = "",
>> string const lyxname_ = "");

I agree that we should get rid of x11name, because it is not so useful
anymore, but I would rather replace it by something like RGBColor (or maybe
merge RGBColor with ColorEntry). Anyway, this is for later and unrelated to
the branch change.

> Georg's solution may look complicated, but it's just a refactoring of
> existing, working code.

Yes. It would be a pity to ditch this code together with the xforms frontend
if it is useful somewhere else.
I think I am going to apply the patch this evening (will send Changelog
then, too).

> A real RGBColor class has real advantages, not 
> least being type safe. We (you :)) should strive to remove kludges, not
> add to them!
> 
> Further, a real Color lends itself to easy manipulation; the fact that we
> have to separately define the colours of inset button and borders is a
> real ugliness!

This is something that can come later. For now, I am only interested in
making the color handling of branches easier/more robust.
At a later point we could think of making branches using a LColor instead of
RGBColor. That would mean that we either add a new LColor for every user
defined color, or a special "general purpose color" that has no name but
rgb values. I am not sure yet what would be best, but we are not in a
hurry: 1.4.x bugs are waiting!


Georg

Reply via email to