> 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 suddenly have doubts about this combination effort, in light of this conversation, since CVPCB works entirely from a netlist file as its input. This issue brings front and center the need for a complete design on the very topic we are discussing. A main driver for me to do this, besides code re-use, was the value in re-use of the background thread, benefiting both PCBNEW and CVPCB, either of which need the "data on demand" FP_LIB_TABLE. I tried, but I don't see how I can extricate myself from a continuing dialogue on this subject. The nice thing about the data on demand concept is the user of the data does not actually have to know where the data came from or even when it arrived. If there was a NETLIST* PROJECT::SchNetList() "data on demand" function for now, I could continue. That is really all I need for now. I can load the existing netlist file for now behind that "data on demand" function, and you guys can augment/replace the implementation later with something else? _______________________________________________ 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
