gEDA-dev: gschem modifications

[Peter Clifton]

On Fri, 2006-07-21 at 10:39 -0400, Stuart Brorson wrote:
> Peter --
> 
> Everything you're doing sounds ultra-cool.  Thanks for tackling this
> project.  Please be sure to get onto #geda during our upcoming code
> sprint this Sunday (from 10:00 US EST until whenever).

I'll try to... that should be 4PM onwards in th UK, and I'm negotiating
secirity access to the department over the weekend.

> Some comments:
> 
> *  Component manager:  Others here have begged for a facility like
> DxDataBook.  This is a fine program, and is worth emulating.  If you
> don't know what it is, DxDataBook is a GUI front end for a database
> which makes it easy to do parametric searches of your component's
> attributes.  It presents you with a list of components which meet your
> search  criteria, and you can double-click on one and place it into
> your schematic.

I'm not familiar with it, but sounds like it would be a useful place to
start looking with regards the design process. Do you know if there is
an evaluation version?

> *  I do think that a database-driven component manager/selector should
> be a separate app to gschem.  That is, it should be its own process
> and be able to run stand-alone (until you wnat to place a component,
> that is).  If you try to graft it into gschem, then gschem's code base
> will grow to a grotesque size.  

I'd intended to make it a seperate application (Probably in Python / C),
and use some library with IPC (or IPC directly) to link into gschem /
PCB / gattrib?

> *  When instantiating a symbol into the schematic, the component
> manager/selctor should just take a stock symbol, and stuff the
> attributes into it and place the attributes at the schematic level.  I
> am a strong believer that attributes should live in the schematic, not
> in the symbol.   That also plays nicely with gattrib, which does
> attribute editing at the schematic level.

> *  This means that the database holds all attributes fo the part, and
> only a pointer to the symbol -- not the symbol itself.  This helps a
> lot since later you can imagine having several possible symbols for a
> single part -- for example, the same resistor part can have be used
> with a box symbol for Europeans, and a zig-zag symbol for Americans. 

Sounds like a nice way to do things. I'm also mindful that for our
purposes, we need a library "manager" which is able to cut down the list
of available components. Eg.. for our teaching purposes, we don't need /
want vast lists of FPGA symbols. Perhaps this could be done by
customising the gafrc file to include or not-include various directories
of parts.

Thanks for your reply,

Peter