> I'd personally suggest using a directory with .sym files, rather than > using a "magic" .sch file to embed all locally instantiated / edited > symbols, although as you'll read below, this could all be a back-end > detail.
I guess a filesystem backed solution would work, might be some issues with portability if you want to implement project hierarchy or sharing within/between projects. I'm not sure I'd want to have to duplicate the symbol data for each customized component, but being able to reference a symbol/component file from another component file would work. So you could have something like this: ./db/ ./db/capacitor-1.sym ./db/capacitor-1_0805.comp ./db/capacitor-1_0805_0.1uF.comp ./db/capacitor-1_0805_1uF.comp ./db/capacitor-2.sym ./db/capacitor-2_ta3216.comp ./db/capacitor-2_ta3216_10uF_16V.comp ./db/capacitor-2_ta3216_100uF_10V.comp > If we can teach gschem to edit a symbol from a memory buffer (dropping > the implicit assumption of a filename, but adding that of some "save" > callback), then saving (in this case) be hooked up the new component > source write API, or to update the embedded data in the embedding case. This may not be needed because we could have a modal dialog which allows a customized version of a symbol to be defined/edited. > There are the drc and drc2 backends for gnetlist - although I'm not > familiar with their operation, or what they will check. I was thinking that would be the place to implement it, so I'll checkout the current implementation. Robert _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
