On Thu, 2008-01-03 at 01:26 +0000, Robert Fitzsimons wrote: > I was thinking about the recent Parts DB discussion and I would like to > see some form of feature like this added to the geda tools. My main > problem is that the task is too large to implement in a reasonable > amount of time. It is also very controversial because of database > backend integration and the added dependences that this would lead too. > > So my idea is to try adding a storage and referencing mechanism which > would allow a project specific customized components to be referenced > from multiple schematic files. > > The customized components would be stored in a special type of sch file; > a separate components would exist for each type of component used in a > project and have all the suitable attributes set (value, footprint, > etc.); the component would have a suitable text reference value defined. > The existing sch file format would be extended to store a reference to > the special sch file(s) or through a config file, and a new component > reference type would be used to link to the customized component using > the text reference value. > > Suitable GUI changes would be needed to allow component selection and > customization, but I would see these as extensions to the existing > dialog. Code changes would hopefully be limited to the component > processing, with significant refactoring to support these abstract > component references. Though I think the changes could be implemented > incrementally, possibly providing suitable hooks for database backed > plugins. > > Does this make sense?
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. We probably want to implement an addition to the component source API, giving it a new "write" API to create new components from data inside libgeda. (Or update old ones). If we add a hook for executing code at component placement time, this gives an opportune moment to write library-sourced .sym file data into the "local library" component source. Assuming the component sources are ordered in precedence correctly, referencing the component by name should pick up the local version. If in copying the symbol locally, we need / want to rename it, then the hook could alter the name of the component being placed to that of the copy. This may work nicely with "Hierarchy->Down symbol" too. There is a bug open (I opened it), for the fact you can't descend into an embedded symbol and alter it inside the schematic page. 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. Throwing in a few dialogs like "duplicate to component source" (where it offers you a name, and a list of any writable component sources or a file as possible targets) would give us the makings of something quite flexible. Note that by keeping the API changes to "writable component sources", we can define back-ends in a similar flexible way to how we currently have component sources. Writing could involve a scheme procedure, or a call-out to an external program. Those people wanting to use databases to store local symbols would be able to use this as desired. [snip controversial discussion topics] > P.S. Separately I like to see some features which would allow Design > Rule Check's to be preformed on schematic files. There are the drc and drc2 backends for gnetlist - although I'm not familiar with their operation, or what they will check. What design rule checks did you have in mind? -- Peter Clifton Electrical Engineering Division, Engineering Department, University of Cambridge, 9, JJ Thomson Avenue, Cambridge CB3 0FA Tel: +44 (0)7729 980173 - (No signal in the lab!) _______________________________________________ geda-dev mailing list [email protected] http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
