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

[DJ Delorie <dj@xxxxxxxxxxx>]

> > However, we could collect stats
> > about things downloaded from, say, gedasymbols.  Perhaps we could have
> > a small number of "starter" libraries on gedasymbols, and the geda
> > installer prompts you to pick one to download.  We track how many
> > downloads of each, and use that to decide which to include in the
> > distribution.
> 
> That's a good idea, as long as the symbols are easy to install -
> probably a good idea to add an option to download and install them,
> sorta like Firefox's add-ons manager.

I think we should start thinking in terms of libraries, not individual
symbols.  Adding a gedasymbols library should be as simple as
downloading some metadata about the library (title, author, url,
copyright, index, description) and then choosing if you wanted to
download a tarball for local access, or talking to gedasymbols
directly (automatic updates might break your schematic though).

Such libraries can be as small as a few parts, or as big as a digikey
database, but we should expect them to include both symbols and
footprints, and if we got the metadata route, the metadata.  I.e. make
them self-contained.

or libraries could have a "depends-on" tag in them for other
libraries, I suppose.  A Renesas MCU symbol library could depend on a
generic chip package footprint library.

We should still support individual symbols and footprints, of course,
but I'm thinking the expectations work better if we prefer groups of
self-consistent symbols and footprints.  For example, a transistor
from the Vanessa library would use footprints from the Vanessa
library, even if same-named footprints were available elsewhere.
Hmmm... we'd have to keep track of the "chain of origin" for each
symbol/footprint, so if you modify a Vanessa footprint and store it in
your local library, the tools know to use that one instead of the
original Vanessa one.

> It would probably require a database, yeah.  Still, I was thinking
> of it in terms of filtering the view against the entire library, and
> the user could have all checkboxes ticked if they want to see
> everything all at once (i.e. like now).

Yup.  I figured you could have site rules, project rules, and if that
doesn't narrow it down, a popup telling you what choices remained.
The "project rules" would be your checkboxes, either a custom menu
that turns into a database query, or data-driven "pick from the
following" like digikey's search engine.  With clever database
choices, they'd both be the same anyway :-)

But if we're adding support for multiple libraries, that complicates
things.  I'm not sure if such a feature (multiple libraries) belongs
in geda/pcb themselves, or hidden behind some data server that
combines the available libraries and presents one unified library to
the tools.  But enabling/disabling libraries could serve the same
function as your filter box, if the libraries are set up right.

Maybe we'll end up needing both.


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