Re: gEDA-dev: SoC Hopeful

[Dan McMahill <dan-at-NOSPAMmcmahill_dot_net>]

Peter Clifton wrote:
> On Mon, 2007-03-19 at 23:45 -0400, Bob Sherbert wrote:
> 
>>Hello again,
>>First off, I'd like to thank you all for the information and ideas
>>provided, everything was very helpful in figuring my way around.
>>Second, I've taken a lot of the suggestions in your messages as well
>>as a few ideas of my own and hashed them into a design I think might
>>be workable for a parts manager.  I'm submitting it here for
>>comments/critiques/suggestions before I go and write my formal
>>proposal. 
> 
> 
> This all sounds good. I look forward to seeing your proposal. I look
> forward to seeing it coded up too! I suspect once you've got the
> data-structures solid, the code will "fall out". Figuring out the
> data-structures was always my stumbling block.
> 
> I'll be keeping an interested eye on this project, as its something I've
> fancied doing for a while - just never had the time. I might even be
> able to help as I'm still doing re-factoring work on libgeda and gschem.
> Certainly let me know where you need IPC to gschem + PCB, as I was
> implementing some rudimentary DBus support in PCB, and intended to do
> similar for gschem once its internals were tidied up.
> 
> How do you envisage managing "versioning" of parts (if we decide to
> bother at all)?

I think we do want to deal with versioning of parts.  I'll add a couple 
of thoughts about that.

- generally you'd like to be able to see if an updated symbol/footprint/ 
whatever exists for the parts in your design but I don't think you want 
to automatically update because sometimes the update is not appropriate 
for a particular design.  For example, you've modified the footprint in 
a way that may make modifying an old design painful and the improvement 
in the footprint isn't worth the change.

- in gschem if you do not embed the symbol (they are not embedded by 
default), you automatically get the updates with no notification or 
anything.  Its even worse.  If a new symbol by the same name ends up in 
your search path before the old one, you'll see the new one.  Ales had 
an idea of using an embedded hash to resolve which symbol to use when 
there were multiple ones of the same name.  I like that idea.

- in pcb, there is not a nice way of updating footprints.  Suppose you 
decide you need to fix a bypass cap footprint and you have 97 of them on 
a big board.  Its a lot of work to update.  Also, when you do update you 
lose things like refdes silkscreen placement.  Here I've wondered if we 
should store the footprint as the original plus changes.  That way you 
can do an update where you keep user changes or overwrite them.  But 
this is getting sidetracked....


> I see you're thinking along the lines of piping output in the standard
> footprint / symbol format. This sounds good. Excusing my poor
> pseudo-bash, would this be something like a helper program to access
> your parts database as:
> 
> gpartman --partid=AD12F397CD23 --type=gschem_symbol -o -

I'm wondering if it is best to communicate with this parts manager at 
runtime or at a "symbol build" time.

> 
> I think it is good to embed these symbols etc.. into the schematic by
> defaulr - so the schematic can then be opened independently of the parts
> manager, especially if the parts-manager fetches from an online
> database. Most if not all the functionality to do this exist already.
> (Anyhow.. a minor point).
> 
> One train of thought I had was to have a .parts directory, which
> contained the symbols / footprints instantiated from the database. SHA1
> IDs (like git source code management uses) is great for making
> file-names to hash-store these sorts of things.
> 




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