Peter TB Brett wrote: > It would also be possible to "export" embedded symbols into a local library, > and to rename embedded symbols without making any library changes. > > My viewpoint on all of this is that it currently seems that detailed > knowledge > of the gschem library system is required in order to gschem & friends at all > effectively. We are severely hampered in our ability to interoperate with > other libgeda tools due to this. Some sort of sane self-contained file > format is not only desirable but *required*, and the current embedding > mechanism fails at this in an embarrassing fashion.
The self containment could still exist without embedding symbol data inline in the schematic file. You could generate a file with a name like: schmatic_name.parts to go with every schmatic_name.sch. That would keep everyone happy and break very few currently-used methods. Breaking the methods of the users with detailed knowledge of the gschem library system isn't necessary or desirable. > > Once the embedding mechanism is in place, I imagine that it would be > relatively straightforward to provide a small command-line application for > managing symbol embedding (for instance via 'make' Could read: Once the embedded parts datafile is in place, users could keep on using their text-processing methods on the .sch files, or use a GUI. The generated files called schmatic_name.parts or schmatic_name.comp could be found and used by gschem on start up as additional library content, according to a library search path. John Griessen -- Ecosensory Austin TX tinyOS devel on: ubuntu Linux; tinyOS v2.0.2; telosb ecosens1 _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user