On Jul 21, 2009, at 10:24 PM, Kai-Martin Knaak wrote: > As you probably know by now, I try to improve the way gnetlist handles > multi part symbols. As a first step, the list of symbols is sorted > according to refdes. Next would be a merge of symbols with the same > refdes. This would also be the right place to check for conflicting > definitions of pins and attributed. > The data structure in the list contains not only attributes and > pins, but > also the graphics of the symbol. This graphics information will be > lost > on merge. > > Obviously this does not affect the pcb back-end, which doesn't care > for > the symbol graphics in any way. Is this true for all back-ends?
Not as far as I know, but not all existing back ends are published. I know of no way a back end can access this information at the present time. But there is the future to consider. I'm unhappy that you're putting another complex, opaque, inflexible mechanism into the gnetlist *front* end. Put hooks into the front end, yes, but leave the back end in control, with default behavior defined in gnetlist.scm. Keep gnetlist flexible for the future: don't stiffen it to make it work just in *your* scenario. The front end code is rather difficult and opaque, as you've discovered. But the back ends, with just a tiny bit of Scheme knowledge, are pretty transparent. Use Ales' brilliant paradigm, don't fight it. > If not, I > have to come up with some more sophisticated way to deal with multi > part > symbols. > > ---<(kaimartin)>--- > -- > Kai-Martin Knaak > Öffentlicher PGP-Schlüssel: > http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 > > > > _______________________________________________ > geda-user mailing list > [email protected] > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user John Doty Noqsi Aerospace, Ltd. http://www.noqsi.com/ [email protected] _______________________________________________ geda-user mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
