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. Dick _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
