On Jun 29, 2010, at 10:16 AM, John Doty wrote: > > On Jun 28, 2010, at 10:56 PM, kai-martin knaak wrote: > >> John Doty wrote: >> >>> You're not thinking of reuse at the same level I am. Consider a Sallen-Key >>> low pass filter. Why should we have to draw that more than once? Somebody >>> could post a symbol along with a source schematic on gedasymbols, and then >>> we could all use it. >> >> see the block paragraph in my section of gedasymbols. E.g: >> http://www.gedasymbols.org/user/kai_martin_knaak/symbols/block/opamp_with_booster.sym > > I was thinking more of a regular schematic, attached to something like > lowpass.sym with a source= attribute. > >> >> Currently, there is a catch, though: >> The symbols are embedded in the schematic. The gschem GUI provides no way to >> get them out of the schematic. The unembed action simply fails, if it can't >> find a matching symbol in the local library. If it saved the symbols locally >> instead, embedding would provide a powerful way to distribute reusable >> circuits. The schematic itself knows best, which symbols it contains. No >> need for a separate application to collect symbols. No packaging of files >> required. Just a single *.sym file. > > I'm not fond of embedded symbols in most cases. I don't embed my .h files in > my .c files either. But since we have embedded symbols, orthogonal design > would suggest that they should be editable and extractable. > >> >> >>> But each application requires different component >>> values, a different op amp, etc. So a file like: >>> >>> R1 value 51.1k >>> U1 device OP90 >> >> IMHO, it is nice to dream about perfect solutions. But we need to get the >> basics straight. The basics in this case is a way to distribute the symbols >> needed for a particular circuit without involving a whole infrastructure. Be >> it a data base, a whole library, or a set of design rules to adhere to. > > That isn't the issue I was trying to address here, and I don't find that > terribly burdensome. It's not much different from managing a software > project, with its include files, libraries, makefiles, etc. Indeed, many of > my gEDA projects include software components anyway, so the tools to manage > such collections of files are already in use. > > I simply do not understand why some find the "cram anything into one file" > attractive for anything but a very small, "throwaway" project. Modularity is > a good thing. Directories and files are excellent tools for organizing > modules. >
It is useful for archival purposes as well. If I want to share a design with the community in it's finished state, then I want it to be in a nice small bundle. but when creating and working on it i want it as modular as possible. >> >> That said, it looks like your are talking about using an editor for the the >> job gattrib does? > > No. gattrib is a "touch-up brush", good for manually fixing little problems, > but not an effective tool of automation. > >> That would be neat. Even better would be, if the file were >> in spread sheet format. Seems to me, gattrib has a hard time reinventing the >> spread sheet GUI wheel. The result feels pretty awkward when compared to >> gnumeric, oocalc and the like. > > Spreadsheets are a slick trap: easy to use, but massive time wasters. > Occasionally, a spreadsheet is effective for a small, simple problem, but > mostly see http://en.wiktionary.org/wiki/fritterware. > >> >> How about this: Use the gschem parser of gattrib to synthesize an >> intermediate file in comma separated spread sheet format. Pipe this file to >> gnumeric/oocalc/whatever. The user manipulate values and attributes and >> saves. > > Violates the ideal flow sources->data products. > >> The non GUI gattrib application detects the changes and writes them >> back to the original gschem file. > > No. Don't corrupt your source file. When you want to annotate the schematic > with specific parameters (component values, slots, etc.) move *forward* to > that annotated file. Keep the source clean for reuse. Keep the parameter > source around so that make can regenerate the annotated product. > Would a cleared way be to express the source schematics as templates? >> I haven't inspected the code yet. But I'd >> expect the this rewrite back-end to be already there in the gattrib source. >> If a user feels like not using a spread sheet application he or she can use >> scripting to manipulate the intermediate file as well. > > Better simply to generate the parameter file with a script straight up. For > the Sallen-Key example, have a script that converts frequency, Q, and > impedance to component values. > I'd like this script to have an interface that allows it to be called from gschem or other applications. >> Ouups, I am guilty of dreaming about perfect solutions, too ;-) >> >> ---<)kaimartin(>--- >> -- >> Kai-Martin Knaak >> Öffentlicher PGP-Schlüssel: >> http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53 >> >> >> >> _______________________________________________ >> geda-user mailing list >> geda-user@moria.seul.org >> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user > > John Doty Noqsi Aerospace, Ltd. > http://www.noqsi.com/ > j...@noqsi.com > > > > > _______________________________________________ > geda-user mailing list > geda-user@moria.seul.org > http://www.seul.org/cgi-bin/mailman/listinfo/geda-user _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
