Re: gEDA-user: Task list for: Solving the light/heavy symbol problem

[DJ Delorie <dj@xxxxxxxxxxx>]

> I will put together such a combined symbol and footprint lib 
> in my section of gedasymbols. May take about a week or so. 

Excellent!  Thanks!

> This implies changes to the way gschem, gnetlist and PCB search for
> libs. Currently, the only way to replace the default library is to
> actually replace them at their original path (with root permission).

Hmmm... I don't think "easy" precludes "setting up directories".  I
meant, the *internal* structure of the library should be such that the
user can unpack the tree, point to it, and go.

> > gschem and pcb both need to be better at referencing multiple
> > libraries of arbitrary depth.  This includes a better way to manage
> > the libraries (gui, config, query rules), enable/disable them, and
> > browse them.  This information should be sharable between tools,
> > specifically, at least, between gschem, gnetlist, and pcb.
> 
> yes, please!

Well, as you test your library, document what problems you encounter
and think about what we'll need to do to Make It Right.  (then do it,
of course ;)

> If we were to introduce the notion of packets, it would change the way
> to look at the data. Without them, we'd have a symbol lib, a footprint 
> lib, a bunch of other data and a web of relations in the database. Packets
> are a way to represent the relations in an intuitive way. They partition 
> the web of relations into, well, handy packets. 
> In addition to the footprint lib and the symbol lib there would be a 
> packet lib.

Yes.  However, I don't want us to have a zillion footprints that are
all the same shape, just because each packet has its own copy, either.
That's just wasteful.

However, if a packet has a *custom* footprint, that's OK.

I'm thinking, the directory structure (or effective tree structure) of
the database should be such that gschem, pcb, and other tools can at
least share a top-level node and the categories, but only see files
relevent to their needs.  Then we can have subdirectories for, say,
Maxim (custom symbols and packet, but no footprints since they're all
standard).  Or subdirectories for Hirose connectors (no symbols since
they're all standard, but custom packets and footprints), etc.  Plus a
section (or sections) for "standard symbols and footprints"

Your packet idea could be implemented as a subdirectory (contains all
the symbols, footprints, models, relations, etc for a single category
of component), or your packet could be a row in a table in such a
directory (i.e. the "1.2k Rohm 0603" row in the Rohm resistors
library), or it could be the whole table if it uses all standard
symbols/footprints (Rohm resistors would, for example, but Maxim
wouldn't).  Or it could be something else of course ;-)

> Packets would change the way gschem, gnetlist or PCB access
> objects. Rather than query directly for footprints, symbols or meta
> data, they would ask the data base to pass the packet. Then they
> would evaluate the contents of the packet to suggest footprints,
> simulation models, or alternative symbols.

My component DB goes one step further - the tool offers the
information it has, and the database passes back *all* the packets
that match, by way of specifying, for each empty attribute, which
values are compatible with the existing ones.  Eventually you filter
it down to one option, and you get that component.

So if you start with "resistor", for example, the next step might be
to pick a value, or a footprint, or a tolerance... but you have to be
able to pick from many packets across many libraries.

> > Gschem and pcb need a way to swap variants on symbols and footprints,
> > for example, switching between resistor-1 and resistor-2, or RESC1608N
> > and RESC1608M.  This depends on the metadata being available (above).
> 
> Did I mention, that packets provide a means for this kind of task?

Yup.  We're past the "should we do it" phase and into the "how should
we do it" phase.

> > Send a reply letting us know what you're working on,
> 
> I'll try to come up with a data format for a packet.

Excellent!


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