Martin Vermeer wrote: > 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.
Of course, but since this would be a document property, it makes sense too. >> 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 :-) If I remember rightly, room 101 contains your worst nightmare. In the case of Winston Smith, rats were going to eat away his face. Do you _really_ want to go down that route or will you not just submit to the will of the state? -- Angus
