On Mon, Aug 04, 2003 at 12:26:32PM +0100, Angus Leeming spake thusly: ... > 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.
I see. Yes... a good idea. And giving those colours names would make sense too. > 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. Yes, but in the dynamic infolist approach you would have both. I see. It would be the job of the code calling the colour picker to make sure a reasonable GUIname gets chosen: in Preferences, the pre-existing GUI element name, in Branches, the branch name. In charactar colours, I suppose the user has to provide the name manually. ... > > 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'. Re-educate me :-) ... > Angus Martin
pgp00000.pgp
Description: PGP signature
