On Wed, Jun 04, 2014 at 03:35:05PM -0400, Wayne Stambaugh wrote: > Backwards compatibility is not optional. We should always be able read
Sorry my fault, I wasn't expressing properly. I meant "reading newer file with older version". Of course newer versions must read older files. > This should be a good start to get the discussion moving in the right > direction. OK. Mmmh... first of all: do we introduce the concept of 'layer name', as user visible/modifiable layer? In this way we could rid of the 'copper layer rename anomaly'. Layer 'tags' would remain F.Cu, B.Cu, Inner1, and so on (I don't remember the default for inners, but that should be the idea). These tags would be the same as the 'standard english' names today, immutable. New layer with behaviour would have significant tags (I have, for example, B.Assembly/F.Assembly/B.Courtyard/F.Courtyard). The keepout would have similar names *if* there were some special handling in pcbnew for them, like DRC. Generic layers without pairing could be named Custom1.User, Custom2.User and so on; generic paired layers would be named F.User1/B.User1, F.User2/B.User2 and so on. I never get the rationale behind the current names so it's just a proposal... these would be simple drawing layers like Eco1 and Eco2; the name assigned would be chosen by the user for the tag. However, where would be the name decided? At board level, system level, module level? At the moment naming is done only at the board level. The modules always uses the tag names. So even if I call in a board layer 15 'Front', for modules it would be 'F.Cu'. However if I decide that F.User1 is, maybe, peelable mask that wouldn't be seen in the module editor. This is IMHO not good (it's the altium approach IIRC). A 'system level' definition would be some kind of mapping in a config file. Too bad that my colleague could use F.User1 for, like, plating information. OK, then suppose we add the layer table to the module object. Quite plausible. In my modules I have tag F.User1 with name 'Front Peel'. My colleague would like to insert it in a board where F.User1 has name 'Front Plating'. What would happen? Either a) it goes mismatched and you coat where you would have a peel or b) it should go in another layer. Which one? A new one, or maybe in one already called 'Front Peel', merging them? Also my colleague is italian so it has named the layer 'Spellicolabile Sup.'. Such a merge would fail and we would have both 'Spellicolabile Sup.' and 'Front Peel'. Still a mess. As usual with localizable names:P OK; change of plan. Custom layers have arbitrary tags (maybe with a distinctive ".User" at the end, and the standard "F." or "B." for paired layers, so they could be machine recognizable). *By convention* this would be a common english name for them, like KeepOut or KeepOutZ. Ideally, one would enumerate all of these in the world and make a registry, but it's not plausible. However with common names for the most used names conflicts would be reduced. Mismatches simply wouldn't happen. I have a layer tagger F.Peel, he has one tagged F.Plating. When he imports my module a new layer pair is allocated. Fine. Everything works. What about names? I think that these would only serve as a convenience for the user, in the UI. By default they would be the *localized* version of the tag name, if available (of course it will be available only for the builtin ones). So the 'we want them translated' people are happy. On import it would keep the existing name, if already present, or otherwise use the one from the source. In the worst case I get the name in the wrong language the first time, not too bad (ever received an office document from another country? style names are in the 'wrong' language, obviously). At least I have the tag and with a little english (or simply asking the sender) I can fix the visible name... Last thing of importance: how are these mapped to numbers? The little table at the beginning would be useful only for the standard layers; it's a starting point. The first 16 layers are always coppers, and the other ones till 29 have a fixed meaning. IMHO there is way too much code relying on this. I'd say that fixed layers are to be kept together at the beginning. Now we have 29 of them. The #30 is the first custom layer. They need to be dynamically allocated anyway to support merging. Tomorrow we add courtyard and assembly as special layers. Ok, 33 layers are fixed, #34 is the first custom one. It does *not* depend on the file. Today I have my peel layers on 30/31, tomorrow is on 34/35. In memory. Added bonus: no compaction needed for unused layer slots, it happens the next time you load the file. How to do layer slot allocation: first there would be some kind of table mapping layer tags to number, and keeping layer names. Theorically more than one: in the module editor, which table is in use? the current board one or something local to the module? First thing to think really hard about before implementation. The only constraint to allocating slot numbers is the need to flip layers, i.e. determine the paired layer number. For fixed layer it's easy, they are enumerated. Single custom layers don't have the problem. Paired custom layers need to be identified. Other operations are always trivial IIRC. Solution 1: - Preallocate ranges: 0-29 fixed layers 30-37 single custom layers (8 of them) 38-53 paired custom layers (8 pairs) Pros: - It's immediate to flip the layers, they always work that way - A reasonable number like this fits in 64 bits so no fancy bitvector is needed for the mask - Can get lazy in the UI since you know a priori layer allocation Cons: - Limited number of custom layers - 'Wasted' bits in the bitmask (not really a problem, if they are few) Solution 2: - Dynamic 'layer descriptor': 0-29 fixed laywers 30-... free for all (the layer table must fully manage the associations) Pros: - No artificial limits - More flexible allocation if we still limit to a total of 64 bits Cons: - Layer descriptor object (layer table) can get quite complex - Need to specify the layer descriptor each time you need to flip a layer, since you don't know otherwise where the pairs are I don't think there would be performance implications in the choice (flipping is not done often anyway). Also most of the time working on a board is spent routing tracks and moving stuff, all of this layer machinery only work when some kind of addition is needed (i.e. adding a module). The custom layers are there only to be seen and plotted, in fact! This should be a start for discussing the requisites. At last, I forgot: layer groups. I really have no ideas on these (simply because I have no use case for them), I guess they could be another structure in the layer table containing the tags (on file) or the indices (in core) of the member layers. Defining behaviour on merge with conflicting groups could be... interesting. Or maybe simply decide that groups are a board-level only entity (i.e. layers simply starts ungrouped if not already defined). -- 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