kicad-developers team mailing list archive

[Cirilo Bernardo <cirilo_bernardo@xxxxxxxxx>]

----- Original Message -----

> From: Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>
> To: Kicad Developers <kicad-developers@xxxxxxxxxxxxxxxxxxx>
> 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