Comment 4 for bug 699635

I still think that we need literal colours; logical tags would be the wrong approach:

1. There would be too many logical tags needed: I can think of a few hundred possibilities, whose colour highlighting is specifically meaningful to the user. On the other hand, the 8 currently in use should be quite chromatically distinct; there aren't that many available colours.

  For example, one might have a 4 layer board, where the 2nd layer contains 3 different types of power (+5,+3.3,+12).
  Or the 3rd layer might be a screen-ground, while the 4th contains analog and digital grounds.
  Or I might have top-copper.analog, top-copper.digital, top-copper.ground

2. I don't think we could define all of the potential logical names in advance (which would be necessary for a colour scheme), and if we make them definable by the user, we hit exactly the same problem now of a layout's colours changing when it is moved between machines, or after the user has worked on a different board. In fact, it's worse than that: on a board with lots of ground-ish planes, one might use 2 shades of blue and 2 shades of green for the various grounds. On a complex logic board, one might use green for ground, but use the blues for something entirely different. So depending on the board itself, one makes different choices of mapping of colour <-> logical tag.

I'm also entirely happy with the default colours for rats/silk/pads etc. The meaning of a silk screen line doesn't change.

(The other advantage of literal colours is that there is no real change to the interface, just a slight change to the file format; so much easier to implement, and less potentially confusing to use).

Summary: I want to make sure that once I choose colours for a board, they stay that way, until such time as I re-edit *that* file. If I work on a different board, and change preferences to suit it, then return to the first board, the first board shouldn't be altered. i.e. track colours have meaning in the context of the signal and board to which they refer, not as general Xresources. If we had logical tags, we'd still have to ensure that the colour schema (mapping tags to colours) was a property of the board itself.

Thanks - Richard