gEDA-user: Solving the light/heavy symbol problem

[DJ Delorie <dj@xxxxxxxxxxx>]

[Subject changed to start new thread]

> When I first read geda documentation, there were already references
> that this had been discussed ad nauseam.

Sigh, yes.  It's not an easy problem to solve, and I would consider
any solution a "major effort" because it touches everything from
gschem to pcb to sim.  Ideally, it would move pcb-specific stuff out
of gschem, although the ability for the user to manage their library
from either gschem or pcb would be ideal.

Bonus points for backwards compatibility, but I think that would only
make things much harder for us.  I'm willing to start fresh with the
caveat that old designs would need to point to old libraries.  In the
past the desire for backwards compatibility was a stumbling block for
this, but perhaps we just need to accept the breakage.

I'm also willing to consider a new method for auto-generating families
of footprints.  I think M4 is not the preferred method for anyone
anymore, despite a general disagreement about what *is* preferred :-)

> If the default lib is to be changed now, then there should be some kind 
> of new consensus on the heavy/light issue.

IIRC there are a few proposals and/or active solutions in play:

* Standard library is light, users heavyify them (we need a better
  verb for that ;) into a project-specific (or even site-global) heavy
  symbol library.

* Standard library is heavy, users either use those as-is or modify
  them to alternate heavy symbols.

* Standard library is light, the tools automatically heavyify them
  based on some database somewhere (both static and dynamic
  conversions have been seen/suggested).

* Standard library is some mix of heavy/light.  I think this is what
  we have now, although not ideally implemented.

In all cases, one key problem is that there are so many potential
heavy symbols that we cannot possibly have "all" of them.  The
solutions either accept a common subset of heavy symbols or defer the
problem to the user, who only puts effort intothe symbols they needed.

My own proposal (posted in the past) is here:

   http://www.delorie.com/pcb/component-dbs.html

It moves the problem out of gschem and into the netlister, which gives
PCB the opportunity to be part of the process as well (the netlist can
accept input from both gschem and pcb), but adds the requirement for
back-annotation for those who prefer the master schematics to have
that info in them.  It is also an optional step in the flow, so it
doesn't block other solutions (like a heavy-only library).

Note that any solution should have these attributes:

* It should be easy to go from a light symbol to a heavy one, so that
  users can add, say, a generic resistor to a schematic and later
  allocate a specific part to it.  While text editing is technically
  easy, it doesn't streamline into a gui-centric flow, mor is it
  readily scriptable.

* New users should find it easy to make their first PCB.  This might
  mean a "starter" set of heavy symbols, or it might mean the GUI is
  streamlined for heavyifying light ones.

* It should be equally easy for newbies to, say, do their first
  simulation.  This might mean an alternate database for sim vs layout
  with "modes", or it might mean distinct "domains" for heavyifying so
  that one schematic can hold both sets of information, or it might
  mean storing flow-specific heavy data elsewhere and merging in the
  netlister.

* Massively scripted flows should remain massively scriptable, while
  gui-centric flows should remain gui-centric.


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