kicad-developers team mailing list archive

[Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx>]

On Thu, Jul 10, 2014 at 11:14:22AM -0500, Dick Hollenbeck wrote:
> That last sentence seems like an oxymoron to me.  Implementing in C++ should always be no
> more difficult than the design.  The design is where the thinking should happen.
> Conceptually the design may or may not be easy, but the coding should not be harder than
> that either way.

Well, I put design into implementation, then. I meant to say that the
we would need to know how the netlist read/write code is 'freestanding'
i.e. if is tied to some eeschema/pcbnew innard or could be easily called
from cvpcb. Code inspection is needed for that and I was just proposing
the broad idea.

> But agreed, the *.cmp file seems like a relic of old school, pre-KIWAY design.

Kiway or not, it simply redundant information already easily carried by the
netlist file. And another file format to keep handled and maintained (I
like the philosophy of "what isn't there can't be broken")

> In the class PROJECT there is:
> 
> *A* ) the ability to hang data structures derived from PROJECT::_ELEM.
> 
> *B* ) the notion of "data on demand".

I still prefer working with individual applications without a project
manager in the way (*and* in separate process spaces), thanks :D

> The notifying can be done using the KIWAY express messaging.  Rather than sending the $10
> by mail, you could in theory simply say go check the cloak room.

OK, the example was somewhat convoluted, but I *think* I got what you
meant. Other packages work like that (eagle for example, has online
forward/back annotation, and AFAIK so does starcad... both of them are
single program packages); I wasn't proposing to remove the file
interchange (since the netlist is useful anyway), but simply to have
pcbnew write the 'updated' netlist with the footprint changed and
eeschema reading back them for backannotation.

If I remember correctly since the new netlist is fully sexp based there
should be a way to pull it in and manipulate it in a pseudo-DOM model;
then just save it. What I don't know is if the current codebase would
support it inside cvpcb without pulling in too much stuff from eeschema
and pcbnew. Ideally just the netlist data and file handling should go
into common and used by cvpcb.

Of course you could still use kiway messaging to notify of the updates
and maybe trigger reloads (backannotation in eeschema, netlist import in
pcbnew): your 'go check the new netlist file' idea.

-- 
Lorenzo Marcantonio
Logos Srl