On Sun, Dec 14, 2003 at 04:50:42PM +0000, Angus Leeming wrote: > The branches code enable the user to create a custom color for each > branch. That is, new colors are defined for a particular buffer. > However, these colors are stored in the system-wide lcolors variable. > That's a design flaw. > > It seems to me that there are two possible solutions. > 1. Add an LColor member variable to Buffer and use it rather than the > system-wide lcolor variable. > Advantages: easy to code. > Disadvantages: expensive. Every Buffer will have to store the 57 or so > color entries in the system-wide lcolor, just so that the user > _might_ add his own custom colors.
*shrug* How many buffers are there? *look around* One ;-) > Moreover, any changes in the system-wide store must be propogated to > the Buffer stores. Maybe it's not so easy to code after all. That's worse. > 2. Return LColor to its original form, where new colors could not be > added. (I've just cleaned up the LColor API, which is now identical > to the original form; all changes enabling us to add new colors are > 'behind the scenes'.) > Create a new class BufferColor which is empty by default but which > will enable the user to add new colors as he defines branches (and > one day colors for the character dialog.) > Advantages: clean code. > Disadvantages: more code. > > I do think that somethng should be done, however. Moving forward with > a flawed design is a bad idea IMO. I don't have a strong opinion here as I never used that feature myself. Andre'
