Re: gEDA-user: What is the standard of gEDA tools and PCB

[John Griessen <john_g@cibolo.com>]

On Thu, 2003-05-15 at 17:09, chimin yen wrote:
>  upgrade PCB tool to GTK+ GUI, and integrate    Hope this comes true sometime soon.

The first step to repackaging is to split up the pieces as command line
runnable small easy to maintain blocks of code.   Which one do you want
to be responsible for Chimin?  How about wx-python windowing
environment, since it works in windows, Solaris, maybe even Mac OS...
and our circuit design work environment is very much unix/windows so
far.


Splitting the library footprint editing away from trace editing
completely would seem like the biggie to me...  that stops all kinds of
things now that are spaghetti code from being debuggable, maintainable,
changeable...  


Another way to say that is that flags that change footprints are a
problem to clean design.  Better that footprints should simply be cells
that are placed and they could have non-layer properties attached at the
current design drawing level, but changing the pad outline is too
fundamental a change for doing from the current level...needs to be
handled as placing  a different instance of a footprint for sanity of
coding.   


In other words, if you desire a footprint with one pad different, you
place the usual footprint in a cell, smash it, rework it, name it with a
new name, place it.  All those steps int the previous sentence can be
done many different scripted low effort ways, so as to be easy to adapt
and change, but to the current drawing, they should be abstractable as
simply another different placement.  Doing on the fly layer shape
changes is a bad distraction from "just being a placeable cell".  There
are important properties inside a cell that you want to be able to get
to for some circuit design/debug actions like tracing connectivity for
layout versus schematic checking.  That is easy to do with  the concept
that a layout cell is just like a subroutine with its own local
variables that must be mapped to other variables outside it.  Mapping
connectivity inside cells can have completely different "conductor"
names with no trouble -- the cell can have layers that connect to like
layers, and also net names on pins to show preferred connection
locations for nets.  Every cell should have connection layers generated
from default layout layer properties of the cell.  For example, if a
cell has layer3 and a l2l3 via and layer2, that needs to be called one
net and any point intersecting any of those layers will have that
default netname.  That needs to be handled as an internal property of
the placed cell for sanity's sake, and for reuse, so we can have cells
in cells in cells....that all resolve connectivity to the top drawing
names.   Mapping the netnames inside placed cells to the top drawing is
not something the drawing needs to have in its structure.

John Griessen

imagining XML-SVG footprint editor as a pcb addon...
also imagining parts of pcb split out and encapsulated, 
(then partly rewritten), in scripting and GUI and speed optimization
languages, (python, ruby, perl, wx-python, c), with tools like SWIG