Re: functional blocks
If we contemplate changing the PCB file format, it would be nice if we
went with something that was intrinsically extensible. Knowing that
the 5th element in a list with '[' means "clearance" is a bad format,
but seeing "clearance=5mil" in a list of attributes is much better.
We use something suitable as our menu resource, but folks have argued
for XML too. I don't want to bring in something as heavy and complex
as XML, but maybe a small parser like our resource parser that "just
happened" to use XML format would buy us some usefulness at low cost.
For performance reasons, it might be useful to have both an ASCII and
a compiled binary format for these, with a converter. I've done stuff
like this before; parsing a huge ascii file is a CPU hog compared to
something designed to be digested by a program.
Note we already have the ability to store attributes at the layout,
layer, and element level. Perhaps that would be one place to hold new
DRC rules? If we tagged the rulesets, we could then assign those tags
to objects on the board, although storing such tags means a file
format change. Maybe the new format can specify mandatory stuff as
the first few non-tagged values (like line start/end coordinates) and
have everything else be tagged after that (like clearance=1mm) so it's
more free-form? We'd need some meta-rules for specifying defaults.
Re: DRC
Our DRC engine could use a complete rewrite. It doesn't get arcs
right, for example. It would be nice if it told us the *actual*
design rules used (what's the closest cross-net spacing? Smallest
drill? Etc) too.
Re: recursive PCBs
I think the first step in this type of change is to tag layers by
type. I've spec'd this out before, I think, and it's the "Upgrade of
layer and design objects" in our big "statement of work" (SOW):
http://www.geda.seul.org/wiki/geda:pcb_funding_sow
Those items are approximately in do-in-this-order order, but the GUI
stuff can go anywhere. Anyway, layer design tags each layer with a
type, such as "top side silk" or "inner keepout" (a combination of a
"where" and a "what", and optional "invert").
This is the basis for elements-as-pcbs and nested pcbs. The tricky
part is not the data structures, but mapping the various layers in
each submodule. For example, if you imported a two-layer board module
into a four-layer board, what happens? Or an element description with
"keepaway" on "all inner layers", how does that map to a six-layer
board? Etc.
Some of that work can be made easier to code if we switch to C++
officially so we can use a real OO language instead of the OO hack we
currently have. There's a patch in the tracker to make the code
C++-compatible, someone (i.e. me) needs to review it so we can get it
committed and start seeing who'll have problems if we switch to C++.
Then you could have each object know how to draw itself (or part of
itself, usually by layers) just by foo->draw(). I don't think this is
*needed* though. We just need a new object type that is itself a PCB
(or at least the PCB->Data structure, like a Buffer), a way to nest
all the draw/find/select etc stuff, and a way to tell the GUI which
object(s) you're editing. That automatically gives you a footprint
editor too :-)
If you'd rather work on the GUI, though, that's also a needed project.
It would be nice if the GTK gui supported all the modern Gnome stuff,
like dockable toolbars and menus-with-icons. The SOW has an entry for
that also.
_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user