----- Original Message ----- > From: Lorenzo Marcantonio <l.marcanto...@logossrl.com> > To: Kicad Developers <kicad-developers@lists.launchpad.net> > Cc: > Sent: Tuesday, September 3, 2013 8:51 PM > Subject: Re: [Kicad-developers] Experiments and considerations for more > layer > > On Tue, Sep 03, 2013 at 03:41:26AM -0600, Brian F. G. Bidulock wrote: >> Mid-term in the wrong direction. Kicad is like that... > > Look. I have this board due to fabrication for the end of month. > I simply can't implement the whole object model in time *and* do the > board layout to produce it. > > It's a human resource allocation problem :D it's a temporary solution > but *it works*; the optimal solution is not useful if it's not available > for use. > > The kicad object model is not perfect (and anyway everyone has its own > idea of perfect model), but kicad itself is not exactly small. Probably > only you and me know exactly how many time a layer type is > used/iterated/converted in pcbnew:P > > Also if you remember even my type cleanup was partially rejected > becaused they wanted to keep layers as 'simple integer'. And if was > actually a little more than a typedef. A mergeable layerset > implementation would require a full layer class and other objects (as > you said, correctly), but I simply don't think that would be accepted by > the 'steering commitee' of kicad:P I don't like, too, the asymmetry > between the board layer structure (renameable) and the module one (the > 'standard english'). Going generic requires a pervasive layer container > (call it stackup or whatever) and layers would then coordinate with > their own container, or something like that. >
A down side to keeping things manageable (such as merging components into the PCB) would be that there has to be a mapping which KiCAD enforces for the integer layer ID and the usage. That is certainly possible and when implemented I suspect the biggest nuisance would be to people who use custom layers - but even that can be addressed by reserving a block of IDs which KiCAD will never use in the main tree. Time is certainly the biggest thing; it would be great if we had corporate sponsors so people could dedicate their time to the code. I have so much free time that I haven't even been able to implement some rather simple features on the VRML export. Oh well, at least I managed to fix some simple bugs in the VRML code all those months ago when we moved to nanometer units. It would be a great shame if Brian's work didn't eventually merge back into the main tree; I suspect that staging the changes would be at least one full time job though. I was thinking of what minimal implementation of IDF3 import would be of use in KiCAD and I didn't realize that Brian had implemented enough new features to support all of IDF3 and much more. - Cirilo _______________________________________________ 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