kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 07/14/2014 02:49 PM, Tomasz Wlostowski wrote:
> On 14.07.2014 19:59, Dick Hollenbeck wrote:
> 
>> Specifically in this case, the question should have been asked:
>>
>> "does the BOARD need to know about the NETLIST, or does the NETLIST need to know about the
>> BOARD?'
> Dick,
> 
> IMHO neither needs to know about the existence of the other.


That is fine too, information hiding pervades here too.


> 
> NETLIST can be extracted from the board by a separate entity (say, 
> BOARD_NETLISTER). Same for the schematic netlist.
> 
> BOARD can be updated by looking at the differences between NETLISTs made 
> by these two entities. Same for the schematic - the differences just 
> trigger different actions. Change of a footprint in SCH->PCB direction 
> would trigger a reload of the footprint and replacing corresponding 
> primitives in the BOARD. In reverse direction, it would merely change 
> the FPID attribute of the schematic part.
> 
> IMHO it's just a matter of refactoring the BOARD::ReloadNetlist into 
> smaller chunks (each of them responding for a particular change, with 
> the knowledge of how to update the underlying model) and writing a much 
> simpler (just doing pin/part swaps + footprint backannotation) class for 
> eeschema.
> 
> No files involved, just as you said.


Sounds like your brain is clicking on all cylinders.

Time for me to focus mine elsewhere, back to the last bit of milestone B) and then I have
to bone up on SWIG, since I've forgotten everything I ever knew about it.  :)

I'm still intending to combine CVPCB and PCBNEW into the same *.kiface file.  That can be
interpreted as just one step closer to killing it off, if you want, I don't have a stand
on that.  I just see a lot of common code, and with the modular nature coming into play,
it should be less important as to where something resides.

I am also thinking about a scheme to set a background thread loose on the footprint
fetching at the time pcbnew.kiface (with cvpcb built in) is loaded, in an attempt to
reduce the time required to pull up the CVPCB frame.  That discussion could be split into
global and project specific parts I suppose.


I've also wondered this morning if the boost::property_tree could not be made to compile
with our UTF8 class as its core datatype, instead of std::string.  I will be exploring
that soon.  This will make it easier to work with since you get the conversions to and
from wxString by mere assignment and promotion without syntactical junk.


Dick