[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: Database on symbols, footprints and other (was "Re: gattrib")



> Impractical in general. Just reproduces the heavy symbol problem
> behind yet another interface. The software is easy, assembling the
> data is impossible.

No, it doesn't.  It's a way to populate your project specific database
from a much larger field of parts, or navigate through your project
specific database once it's created.  It's a way to look at a large
data set and extract a smaller one from it.  It's a way to
synthetically create a heavy symbol database that's orders of
magnitude larger than what we'd be able to do with
one-symbol-per-partnumber heavy symbols like we (and you) use now.

For example, look at any Digikey catalog (printed, not web).  They
*don't* list all available part numbers, they provide
fill-in-the-blank part numbers for things like resistors and
capacitors.  Wouldn't it be nice to have a plugin that could
synthesize all those part numbers on demand?  So one resistor symbol
and a couple of rules gives you thousands of available heavy symbols,
with little overhead?

Now, you can put the one symbol and the few rules in your project
specific database if you want, but I'd rather have one central
location for all my parts.  However, my idea precludes neither way.

> The package to use for a 4.7k 1/10W 5% resistor and a Digikey part #
> for it.

That doesn't let me say "use any 4.7k resistor, and let someone else
figure out what part (or model) that is".  John, in your case, the
database *is* your project-specific database.  YOU still have the
problem of creating those heavy symbols anyway, choosing among them,
and making design changes at varying steps along the flow.  Why won't
you let us help you make your job easier?

Even if we all used your ideal workflow (which we don't), we still
want to easily solve problems like "I want an LED.  What colors do I
have?"  without having to go groping through a directory looking at
every possible LED we have and somehow remembering what color options
were available.

> is practical. But that kind of mapping can already be done in gschem
> to the extent it makes sense. It's when you want to make wholesale
> decisions downstream that we have no mechanism.

So... I try to add such a mechanism, and you tell me it's the wrong
thing to do?


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