[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