On Sun, Dec 14, 2003 at 04:50:42PM +0000, Angus Leeming spake thusly: > 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. > > 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. > > 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. > > -- > Angus
3. Make the colours defined by the user in one buffer available for use in the others (how? We need to use the name of the colour, i.e., the name of the branch. Extra logic, but perhaps not as much as 1 or 2) -- Martin
pgp00000.pgp
Description: PGP signature
