kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

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.

Last night I also trimmed out the tstamps where not needed, but have not committed yet.

The open issue of changing the non-copper names is best settled if we had a complete list
of proposed names to change to, and to make the determination if this is worth the disruption.