I went through the whole thread again, in chronological order, and tried to maintain a "current opinion" for each of the participants as ideas were tossed around and people changed their minds or agreed/disagreed with others' proposals. Then I collected the results and tried to distill the essence of what I thought people generally agreed on (most people expressed a positive opinion) and some things that were at least uncontested (some people expressed a positive opinion, with no disagreements).
I further tried to remove any "how do we do it" ideas, leaving behind the "what do we need to do" portions. At this point, please reply if you feel I have misrepresented the data at this phase. Otherwise, wait, and I'll write up a starting point for the "how do we do it" phase. Although, some of us (me included) are guilty of jumping the gun on that one anyway :-) GOALS (reiterated in summary) (1) Easy to heavify (not just emacs) (2) Easy for new users to make first board (3) Easy for new users to do first simulation (4) Inertia - preserve massively scripted flows and massively GUI flows. GENERAL AGREEMENTS [Note: you may substitute "model" for "footprint" if you prefer] We need to be able to support both small self-consistent heavy libraries as well as clean light libraries. It should be easier to heavyify objects in light libraries. A new user should have access to one or more small "starter" libraries of self-consistent heavy symbols and footprints. We need to support multiple libraries at the same time within the tools. Relations within a library should prefer matches within the library over matches found elsewhere. Libraries should not be restricted to local files - remote libraries should be usable as-is. Specifically, integration with gedasymbols.org should be better. The symbol/footprint duopoly in our current library is insufficient for our needs. One or more additional categories of information is needed, such as: * symbol class, in which multiple graphical variations of a symbol can be grouped. * Likewise, footprint classes * Some form of data ("metadata") which matches a symbol and footprint with additional data (example: pin mapping, part numbers, values, datasheets) in order to represent a specific component. A "library" may contain both symbols and footprints, and other related data that may be needed for completeness. Each aspect of using the geda suite should be easier to learn, especially for new users, especially heavyifying. UNCONTESTED IDEAS Library browser should allow for filtering, searching, or other means to narrow down the list of options. Filter preferences should be able to be preserved across sessions. Libraries should allow for arbitrary heirarchy within them, with a way to "scope" a reference to something in the library. Links in the library should have preference rules for finding their target (i.e. a "footprint=" looks in the symbol's location (or metadata's location) first, etc). The tools and libraries need to allow a concept of a chip, packet, package, part, component, whatever - grouping all the relevent data (or references to) for a specific "whatever" in one place. *Use* is optional, but *ability* is needed. gattrib needs more integration with the various libraries (search, preview, auto-fill, etc). gschem should have more of this too, to help the user heavyify symbols. It must be possible to change some aspects (where practical) of the design from within pcb/sim (such as selecting a footprint/package, or pin/gate swapping, or a passive's parameters). _______________________________________________ geda-user mailing list geda-user@moria.seul.org http://www.seul.org/cgi-bin/mailman/listinfo/geda-user