Re: gEDA-user: database driven component chooser - part II

[Bert Timmerman <bert.timmerman@xxxxxxxxx>]

Hi all,

Speaking about huge steps: do we actually _know_ how many of the users
are using the gschem-->pcb workflow and how many are using the
gschem-->[gnetlist, something_else] route.

If the "80-20" rule applies in favor of the gschem-->pcb route ...

Anyway, I hope Levente continues with this effort as it looks promising
to me and at least could solve the "transistor" problem.

If this method can be expanded to other netlists that would be fine, and
a benefit.

OTOH, there would be a _lot_ of "content" needed for this mechanism
(to be added and maintainted and checked and double checked).

FWIW, we could always fall back to "light" symbols and manually add all
the necessary attributes and ... err  ;-)

Just my EUR 0.02

Kind regards,

Bert Timmerman.

P.S.: the "80-20" rule could be applied here as: "80% of the user base
uses 20% of the available options gaf offers".

On Mon, 2007-10-01 at 17:50 -0400, Dan McMahill wrote:
> DJ Delorie wrote:
> >> As the relation between 'device' and 'supplier' is a many-many
> >> relationship, you'd be better off creating just another table,
> > 
> > I also recommend (and have been thinking about) a multi-table database.
> > 
> > One maps symbols to a symbol class (i.e. the N different ways to show
> > a resistor), one maps classes to specific parts (manufacturer PN), one
> > maps specific parts to vendors/prices/etc.
> > 
> > The first two are treated like one table (symbol->part) since you
> > don't have a choice about the symbol class, it just "is".  Given some
> > preferences, that's enough to get you to a pcb footprint.  The second
> > table is used to complete the BOM, calculate pricing, and prepare an
> > order.  Also, checking the second table lets you qualify entries in
> > the first table; if you can't order it, don't pick it :-)
> > 
> > I suppose we could have footprint classes, too, to handle the
> > "least/normal/most" suffixes we have for some parts.
> > 
> > Links:
> > http://www.gedasymbols.org/csv.html
> > http://archives.seul.org/geda/dev/Mar-2007/msg00180.html
> 
> At the risk of trying to make one giant perfect step which never happens 
> as opposed to a moderate step in the right direction...  You may want to 
> think about what it may take to be able to include netlist information 
> for different backends.
> 
> In other words, it seems this database is oriented towards having 
> netlisting for pcb Just Work.  If you want to work well with simulators, 
> it may be of use to be able to specify how each heavy symbol will 
> netlist for whatever simulator backend.  There is missing infrastructure 
> in gnetlist and libgeda which would be needed, but it might not hurt 
> keeping it in mind.
> 
> -Dan
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user



_______________________________________________
geda-user mailing list
geda-user@xxxxxxxxxxxxxx
http://www.seul.org/cgi-bin/mailman/listinfo/geda-user