On Thu, Sep 05, 2013 at 05:26:46PM -0700, Cirilo Bernardo wrote: > > I think Tom's class is adequate. I don't think Brian S.'s idea about > > dynamically > > assignable layer slots is optimal. I think fixed layer slots are easier to > > code, but I > > don't see why you have to limit the number of slots with Tom's > > approach. You can have 300 > > layers if you want, but I think you need to pre-assign all of them, and > > chose > > not to use > > but a subset of them on any board.
Exactly like my original approach. > > I think fixed technical layer names are important, both to KiCad branding > > and to > > board > > merging like JP mentioned. Because these names are being indexed by google. LOL... I've *never* tought about the google thing. However I agree with JP (look in the past messages, I've already raised the issue) and also proposed a solution (I admit is not simple) for the generic case. > > This is part of why I don't want to mess with the technical layer names > > that > > are in place > > already and why I yanked the international language translations for them. I think this is not correct for the user, at least in the UI he should see its national names. I agree that it's better to handle the fixed name for the special layers inside files. > > a) specctra numbers copper layers from front to back, starting from zero. > > > > > > b) in contrast, my most recent conversations with bare board houses in > > China had > > them > > numbering layers from back to front, starting at 1 on the back. And the problem is? Altium has separate numbering for signal and coppers, for example... during fabrication for every not-trivial board you have to submit a full stackup specification (with prepregs and so on) containing the gerber names, anyway. > > c) The internal copper bit masks for layers has always bothered me, the > > sequence > > that is. Please elaborate on this. It's like the chinese numbering... what bothers you in that? > > d) Existing problematic code fragments should be identified early in the > > planning phase, > > and any design change should be evaluated on its ability to handle the > > problematic code > > collection. Please start that problematic list with where I output the > > pretty > > layers, and > > extend it by adding to it. I haven't changed a line in the I/O routines since they pull names and number from the layerset. The only problematic thing would be the .* handling which is ad-hoc (and redundant anyway). Also the initial stackup description obviously (*reading* it would be difficult) > > If the result of the first implementation is that you do not depend on > > layer > > numbers > > (much), but rather on names or range checking, then you can shift that > > enumeration at any > > time in the future without causing the source code or existing data files > > any > > grief. Mostly agree with that. It's the same as my proposal. However I think that trying to fixedly enumerate all the possible layer from the start is a lost battle. For non-special layers I think the Altium approach is better if we want to 'fix' the number of layers. > > These LAYERs and LAYER_SET are done using "Tom's 20 minute solution > > plus augmentation, as > > needed". I didn't look closely at that but why not simply use std::bitset then? > > > > If you have based your files on concise English names for all but the Cu > > layers, > > but those > > cu layers are also named, then I don't see any large grief to shift this > > conceptual > > enumeration which runs from 0 - MAX_LAYER. Not only can you make MAX_LAYER > > higher, but > > you can also shift regions of interest within it without radically impact > > code > > or data > > files later. Inner1 and Inner2 are names, anyway... the new format always uses names so it shouldn't be a problem; the layer numbering table at the beginning would describe the bit allocation. AFAIK that change is already possible (with the constraint of keeping copper layers adjacent); the only nuisance is the ranging code in the layer selector (used *only* to exclude the board borders) which would be a minor fix anyway. In substance I think that if we can keep the things between FIRST_COPPER_LAYER...LAST_COPPER_LAYER and FIRST_NON_COPPER_LAYER...LAST_NON_COPPER_LAYER, nothing should break. I would add a FIRST_USER_LAYER...LAST_USER_LAYER subrange reserved for an Altium-like configurable range i.e. non special renameable user layers (so adhesives, draw, comment, eco1, eco2 would fit in that as 'useful defaults'). I already extracted all the pairing code so it only need a way to store which user layer is paired with which (if it's paired). Or, splurge another layer range number and have a range of front-back front-back front-back user layers with fixed pairing and a range of non paired user layers. That would be even simpler to handle. -- Lorenzo Marcantonio Logos Srl _______________________________________________ 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
