Martin Vermeer wrote:
> OK, sounds like an interesting approach. (We'll still end up at 20x
> LOC of the original Branches implementation, don't you worry :-)
Nahhh.
> But... setBackgroundColor still expects a LColor::color argument,
> not an integer (or an id string, which would be better in a way).
Well, I haven't thought through all the consequences, but I am
basically suggesting that LColor moves from a static, compile-time
list of available colours, to a dynamic, run-time list.
This would be of use in places other than your Branches code. Eg, in
defining new colours for latex export; something that Juergen
Spitzmueller has expressed an interest in in the not too distant past.
Of course, this means that all code that expects an LColor::color
argument should be rewritten to take/use either a string 'name' or an
RGB struct. I prefer the encapsulation intent of the former but can
see that RGB has the advantage of transparency.
Eitherway, because we would now be using dynamic list of available
colours, we would need the accessor functions in LColor itself to
check that the name is indeed valid. Eg
string LColor::getGUIName(string const color) {
support::Assert(name_is_registered(color));
return infotab[color].guiname;
}
> Remember though that for *my* purpose, all I want to do is specify
> an RGB colour and then paint it to the screen... nothing goes to
> LaTeX, nothing has syntactic significance for the LyX GUI. [Your
> original argument for making these colours just RGB triplets!]
> Making them complete infotab entries just feels a bit like overkill.
Sure. I understand this too. I'm just trying to see the best way
forward.
> Have a look at the attached patch. If I add methods fillRectangle
> and setBackgroundColor to the appropriate places ((X)Painter and
> InsetBranch) taking a string instead of an lcolor, then I am
> finished... any X11 colour (including #ff8a48!) can be directly
> painted as a branch inset background.
>
> Does this make sense?
Yes. But I'll wager that the thought police will not let this one get
past them. I'm afraid that you will be taken in for 're-education'.
>> > Why not use XAllocColor directly as it was made for this?
>>
>> Think of Qt running on a Windows box...
>
> ColorHandler is inside xforms only. And I am pretty sure that also
> other environments handle RGB values easier that the LyX specific
> LColors colours, and could be similarly adapted.
This all feels a little like a can of worms. However, it also feels
'right', whatever right means...
--
Angus
