> I assume that's the reason for PCB, too. No, pcb's plugins are very tightly coupled to the internal data structures. The reason I added pcb's plugins was to let people define their own actions without the cvs-build-merge issues, not as a generic way to allow for future expansion.
> You have the order backwards. Design the file format first, > then the data structures. The file format should be designed > as a language for expressing what you want to express. PCB has a second format it uses called a "resource file". It's a semi-lisp-ish format that allows for arbitrarily nested data, without the complexities of XML (the whole parser is about a page of code). It could be used to hold pretty much anything, but it isn't "designed for the data". > > * Finally, how should PCB behave with a hierarchical > > schematic? > > Right click on a symbol, select "go inside", and another drawing > opens up showing what's inside. gschem also should act this > way. I think pcb "blocks" should be translucent. You should have some idea of the physical contents of a block even when you're not editing it. _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user