> > 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@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user