kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 11/12/2012 03:38 PM, Dick Hollenbeck wrote:
> 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 

oops, no "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.
>