[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: gEDA-user: Design Flow Roadmap starting point
> 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@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user