gEDA-user: Draft consensus on: Solving the light/heavy symbol problem, "what" phase

[DJ Delorie <dj@xxxxxxxxxxx>]

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