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

[Geoff Swan <shinobi.jack@xxxxxxxxx>]

   I really don't want any *major* changes to the core workflow and UI
   TBH.
   The changes that would make this a more complete tool (for me anyway)
   are:
   PCB:
   - better control over polygons. Ie better awareness/ability to tie to
   nets, built in crosshatching (intstead of solid), and an option to hide
   all polygons without having to put them on a separate layer (this
   messes with DRC)  (thin draw poly is cool though!)
   - footprints: native text capability, polygons, manual solder-mask,
   manual paste mask
   - A manual paste layer
   - Not sure about how to describe this, but I think it comes under the
   back-annotation editing of symbols... PCB is a little thin on the
   ground when it comes to editing elements on the fly (can you even edit
   text from the gui once placed?)
   gschem: not too many changes as I see it...
   - A footprint viewer - when selecting/setting a footprint it would be
   nice to have a preview (this could most likely be done as some sort of
   plugin)
   - A more complete channelisation/subcircuit/bus concept - basically
   just tie buses and subcircuits together (i think I may try and do this
   myself - i've asked about it before and got some useful feedback)
   Light vs heavy
   I think this has all been said but *my* summary is
   * you can never have *all* the heavy symbols - and chances are most of
   your heavy symbols will be useful as is to less than half gEDAs users.
   * purely light symbols leave beginners wondering why their projects
   don't compile out of the box
   solution (as discussed) - set up a default beginner/base library with a
   subset of the most commonly used components (defined by how much time
   and effort people are prepared to put in I guess) that is shipped -
   don't do anything to over complicate the heavyfication process - as it
   stands is fine :)
   I think tying gschem and pcb together more closely is a separate task -
   DJs database.
   I've been thinking of attempting to do this myself for some time - i'm
   as far along as writing a base schema to capture the core
   information...
   A functional component can take on many forms - the alignment of
   function to pin and whether the function is available is interdependent
   with the choice of footprint, functions can be remapped amongst pins
   (look at most ARM chips). Ideally one should be able to define a
   functional requirement in the schematic, swapping which pin provides
   said function in the final layout shouldn't be a major chore.
   I don't think this is an improvement that needs to be made in gschem -
   gschem is for schematic capture, which it does fine.
   Parts/symbol/component management is a separate task, so long as gschem
   doesn't hinder this process great - if it can include some plugins to
   make the task better integrated (such as a footprint preview) even
   better. A tool like gschem shouldn't be tied up trying to define and
   handle all variations of what any given person thinks makes up a
   symbol. It already has the capability to have arbitrary text attributes
   - that's enough. Just link the gschem symbol to the database/tool
   (separate program) that handles the various symbol permutations via a
   unique ID of some description or other...
   Anyway - the database idea has been looked at before, and from memory
   even implemented somewhat; so its nothing new.
   Geoff
   (If anyone is interested in the schema I've started
   [1]http://nixotic.com/partsdb.png)

References

   1. http://nixotic.com/partsdb.png


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