On 11/12/2012 12:19 PM, Wayne Stambaugh wrote:
On 11/11/2012 9:46 AM, Dick Hollenbeck wrote:
On 11/11/2012 08:07 AM, Wayne Stambaugh wrote:
On 11/10/2012 11:13 PM, Dick Hollenbeck wrote:
*Observations:*
a) Layernames should be in English always (in a footprint, not a board).
Once we go down this path, we can never change the English default layer names without
maintaining support for the current spelling of the ones you see now.
I knew this had the potential to be an issue when I designed the new
file format. I am not opposed to going back to a hexadecimal bit mask
for layer definition. Now would be the time to do it before we make the
new file format the default. We would be trading human readability and
potentially unlimited layers (I'm not sure that is important) for a
smaller file size, faster layer parsing, and easier maintenance. There
are sound arguments for both designs. Internally Pcbnew layers are
still bit masks so the number of layers are limited to the integer size.
Any move to a layer stack would require major changes. It does seem
that a hexadecimal bit mask is more appropriate given our current
design. We can always move from a 32 bit to a 64 bit layer mask when
users start requesting more copper layers.
Wayne
The layering *order* in pcbnew is questionable, and something I've been arguing to change
for 4 years. Therefore the hexadecimal numbering scheme is more likely to become obsolete
than is a well thought out English layer name.
I also don't think you have a speed problem parsing layer names. We can get an
improvement using std::string in stead of wxString for the hashtable. There's not a lot
of point in converting to wxString before doing compares or hash functions. But this is
MINOR.
When I load a *.kicad_pcb file now, it loads at about the same speed as a legacy load on
the same *large* board.
We do not have a problem. I am in favor of staying with the current game plan, although
would be open to another look at English layer name *spellings*, NOW. Personally the
spellings seem clear, but I am not certain about conciseness, but don't take that as an
objection to current conciseness. Practically, we may already be past the point where
they can be changed without disruption.
It shouldn't be a problem for legacy board files. Only the copper layer
names are saved in the legacy format which are about as concise as you
can make them without abbreviating. There shouldn't be too many sexpr
files around other than a few developers so if we are going to change
the English names, then now is the time. I could see dropping the
underscores from the camel case names and drop the "PCB_" from
"PCB_Edges" since PCB is implied. Another option is to drop the vowels
from the layer names so "SilkS_Back" becomes "SlkScrnBck". In some
cases the name will not be any fewer characters but would be more
readable. I'm assuming that by concise that you mean as short as
possible without any loss in readability.
Yes, "as short as possible without any loss in readability", is a concise definition of
concise.
Agree that copper names are now already optimal.
Extending your suggesting further, what about using a leading or trailing 'B' (=Back) or
'F' (=Front), rather than the suffix of Bck?
BSlkScrn
FSlkScrn
etc.
(These non-cu name changes, although improvements that I would enjoy, still leave me less
than 100% comfortable this late in the game. I am concerned about how this propagates
into the layer manager user interface, where the user sets up his board names. Are you OK
with these names there too? Don't remember if we have layer specific tool tips there, but
that would help.)
I also coded last night some support to compress the "all copper stack" found in through
hole pads into "*.cu", that is *.cu.
This 4 character sequence is about as concise as you can get there too. This will have a
tremendous impact on reducing the size of through hole pads, and leaves the door open to
more copper layers down the road. This simply means all cu layers.
