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. > _______________________________________________ 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
