On 07/10/2014 10:34 AM, Lorenzo Marcantonio wrote: > On Thu, Jul 10, 2014 at 05:22:20PM +0200, Michael Heidinger wrote: >> Sure that is a solution for me, but not a solution for a production >> software. >> (Other users will be confused, that's why I report that bug) > > It's a veeeery old issue, that of the cmp file... but at least now there > is not anymore a separate backannotation file to handle, we're > progressing! > > I think the solution would be to get rid of the cmp file altogether and > only use the netlist as a communication point. Alas I have no idea of > the feasibility to apply the netlist reader and writer outside their > current environment (cvpcb would have to read the netlist and write it > back with the new footprints; after this eeschema would have to > read it back to do backannotation). That would also remove the need for > the 'use netlist or cmp for footprint' option in pcbnew. > > Conceptually it's easy but implementation could be tricky...
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. But agreed, the *.cmp file seems like a relic of old school, pre-KIWAY design. In the class PROJECT there is: *A* ) the ability to hang data structures derived from PROJECT::_ELEM. *B* ) the notion of "data on demand". The FP_LIB_TABLE is currently the only class which benefits from these two support elements. A clean netlist class could also benefit. The purpose of *A* ) is to hide information about the data structures from the PROJECT class itself. This is like a cloak room attendant who hangs coats, without looking into the pockets of each coat. When the attendant starts looking into the coat pockets, you get header file dependency expansion, and information hiding gets out of control. The purpose of *B* ) is to defer the loading of the data structure until the last possible moment, the time of first use. There is then no actual explicitly needed "load" call required by the first user. That is hidden behind the (read only) pointer retrieval accessor (and implemented anywhere). Hopefully the loader implementation is done in one place so as to not duplicate code, and this loader (& saver ?) implementation should take care to not expose the pocket contents to the cloak room attendant. Then, there is additional support in the form of the new "KIWAY express", to notify anyone that the contents of the pockets have changed. This is like getting two coat check tickets. You could put 10 bucks into the pocket of your coat, and send your wife into the cloak room to fetch it. You just have to notify your wife that there's another 10 bucks in there. (Suggest keeping it under $10 per hour.) 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. If you're lucky, your wife can say thank you. Although she may make you go to the cloak room to actually read that message, using the KIWAY express to simply say you have a surprise in there. In my case it would be me getting the $10, from her. _______________________________________________ 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
