Re: gEDA-user: Solving the light/heavy symbol problem

[Cullen Newsom <cullennewsom@xxxxxxxxx>]

   Oh boy am I glad y'all are having this conversation, and I hope you
   don't mind some comments from the peanut gallery.

   On Fri, May 20, 2011 at 11:01 AM, DJ Delorie <[1]dj@xxxxxxxxxxx> wrote:

     [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.


   No it isn't easy but for the reasons mentioned above has the potential
   to improve gEDA usability (ergo adoption) in significant ways.

       ...the ability for the user to manage their library
     from either gschem or pcb would be ideal.

   Yes please! (right click and or hotkey -> attach footprint to symbol)

     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
     :-)

   Put me down for intense dislike of M4. Sorry. I'm sure it's a fine
   choice for some, but I've never had to touch or know anything about M4
   for anything else, ever. Which means that on some occasion that all I
   had wanted to do was make a printed circuit board; now I have to go and
   learn enough about M4 to make my little footprint(s). It also means
   that I'll probably do something wrong, or in a non-optimal way, since
   I'll never use it enough to achieve any sort of proficiency.
   tl;dr I would love an easier way to generate footprints.

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

   There are many perfectly reasonable occasions / individuals who would
   prefer the heavy option.
   It is also reasonable to say that the light option gets you the most
   flexibility.
   After years of watching this debate go nowhere, may I suggest that you
   must either find a way to do both, or tell some of us to bugger off.

     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.

   Nobody needs all possible heavy symbols, and disk space is cheap.

      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.


   Which puts many (often novice users) to the task of creating their own
   symbol/footprints, and probably doing it wrong. This is bad for so many
   reasons, not the least of which is that there will be so much
   duplicated effort spent on a very mundane task, like creating a
   symbol/footprint for some three-terminal regulator, or TTL logic gate
   or something.

     My own proposal (posted in the past) is here:
       [2]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.

   Yes! New users, casual users, experienced users, all users.

      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.

   My suggestion for symbols and footprints (and maybe other / metadata).
   Don't ship gSchem or PCB with any. At first run, and in preferences,
   and in config files, give users the ability to choose their own poison.
   Use git to synchronize with a (set of) master symbol and or footprints,
   and or something else databases. Include options to use others' symbols
   / parts (gedasymbols, luciani, etc). Include options for users to share
   their own symbols via git. Create online symbol and footprint
   generators that create standard footprints (at least for JEDEC standard
   stuff) properly (according to best practices).
   By the way, if you guys decide to tackle a big re-write, the IPC and
   NIST tried to tackle this problem a few years ago. I don't know what
   ended up happening to their efforts, but it might be worth looking at
   what they did. They produced a nice little GUI thing which can be
   downloaded at the link:
   [3]http://webstds.ipc.org/viewer/Offspringviewer.htm#
   Many Thanks,
   -CN

References

   1. mailto:dj@xxxxxxxxxxx
   2. http://www.delorie.com/pcb/component-dbs.html
   3. http://webstds.ipc.org/viewer/Offspringviewer.htm


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