Layer colours should be saved in the .pcb file itself.

[richardneill]

For each new PCB that I make, the layer mapping, layer names, and layer meanings are different.

For example, I might make a 1 layer board, with:
  LAYER GROUP NAME COLOUR
    1 1 solder grey
    2 1 ground dark blue
    3 1 power orange
    4... (unused)

Or I might make an 8 layer board, where the layer mapping begins:
  LAYER GROUP NAME COLOUR
    1 1 solder grey
    2 2 digital_ground dark blue
    3 2 analog_ground dark green #NOT orange!
    4... etc

This example should illustrate that the colour is (by personal preference) a property of the layer's name in that particular PCB design, not a generic property of the layer's number. Likewise, if I change the colour scheme of one board, I don't want that change to apply to an older board when I revisit it.

Therefore, it's very confusing that the colour scheme is not kept with the rest of the board's metadata (such as name, grid-size, layer-names etc). It's especially problematic when the .pcb file is moved around between computers.

I agree that one's default choices belong in ~/.pcb, but please could you make the .pcb file itself save the colour details.
Thanks.

[Ineiev (ineiev)]

Actually this is a feature request rather than a bug report; the feature was implemented a year ago;
the patchset lives here:
http://repo.or.cz/w/geda-pcb/dti.git/shortlog/refs/heads/attributes

[DJ Delorie (djdelorie)]

Moving to the feature request tracker

[Colin D Bennett (colinb)]

Rather than store the colors directly in the .pcb file, I would prefer seeing logical tags that the user's current color scheme maps to actual colors. I'd like to be able to switch color schemes (e.g., light vs. dark) and have my layout still be readable. Tags such as "top-copper", "bottom-copper", "layer2", "layer3", "top-copper.ground", "top-copper.pwr", etc. would support a wide variety of both 2-layer and 4-layer board configurations.

Also, wherever you define layer colors, you'll need to define all the other colors such as rats, silk, pads, vias, selected line colors, far-side element color, background, etc. since these will need to be visually compatible with the layer colors.

[RichardNeill (ubuntu-richardneill)]

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