[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: gEDA-dev: gschem modifications
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
_______________________________________________
geda-dev mailing list
geda-dev@moria.seul.org
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev