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