Martin Vermeer wrote: > On Tue, Jul 22, 2003 at 12:24:41PM +0100, Angus Leeming spake > thusly: > >> Martin Vermeer wrote: >> >> > >> > Probably. Why not. But how to save the colour into the doc file? >> > Having the colours named has value. What If I extend the list of >> > available colours to include more rgb.txt entries? Note also that >> > blue and red should probably go as they are too dark for >> > background. >> >> Why not define logical colours "branch1", "branch2" etc which you >> save in the doc. Adding them to the LColor.h enum and LColor.C >> array of all such colours will automagically allow the user to >> specify their on-screen representation from the preferences dialog. >> >> -- >> Angus > > Interesting idea. Hmmm. You mean that the choice_color widget would > present the names "branch1", "branch2" etc. to the user? A bit > prosaic.
Maybe. Or maybe the dialog will simply inform the user that this newly defined branch will be presented in colour "branch5". If they aren't happy with the physical appearance, then they'll pop along to the preferences dialog and modify it. > My idea was to add to LColor a number of existing colours found in > rgb.txt, suitable as background colours under black text. These > would then be absolute, not logical. Is there really much sense in > allowing the user to redefine these? I mean, they don't "logically" > represent anything, the're just supposed to be all different. You use a pale background and black text. Someone with poor eyesight will use a dark background and pale text. Your sets of 'suitable' will differ. -- Angus
