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

[Kai-Martin Knaak <kmk@xxxxxxxxxxxx>]

DJ Delorie wrote:

> 
>> I will put together such a combined symbol and footprint lib 
>> in my section of gedasymbols. May take about a week or so. 
> 
> Excellent!  Thanks!

After I skipped through what needs to be done, I have to admit that 
it will take a bit longer. 

 
> Hmmm... I don't think "easy" precludes "setting up directories".  I
> meant, the *internal* structure of the library should be such that the
> user can unpack the tree, point to it, and go.

For symbols this means a flat tree with no subdirectories at all.
I'd say, the search routine of the add symbol dialog really should 
be enhanced recursively descend to directories.
 

> Yes.  However, I don't want us to have a zillion footprints that are
> all the same shape, just because each packet has its own copy, either.

This is why footprints symbols and essentially any other objects 
can be embedded in the packet, or referenced. It is up to the designer
of the packet library to decide what is the mos useful.  

> However, if a packet has a *custom* footprint, that's OK.

That's what I meant :-)


> Your packet idea could be implemented as a subdirectory (contains all
> the symbols, footprints, models, relations, etc for a single category
> of component),

So an object "embedded" in the packet would just be a file in the 
subdir. I like this. It turns embedding into a reference to the 
local directory. At the heart of the packet would be a file that
gives all the relations and defaults.


> My component DB goes one step further - the tool offers the
> information it has, and the database passes back *all* the packets
> that match, by way of specifying, for each empty attribute, which
> values are compatible with the existing ones.  Eventually you filter
> it down to one option, and you get that component.

How would you communicate the rules you taught the database to 
colleagues? Say, there is a brand new series of FPGAs you'd like 
to share.


> So if you start with "resistor", for example, the next step might be
> to pick a value, or a footprint, or a tolerance... but you have to be
> able to pick from many packets across many libraries.

We'll have to be careful to make this transparent to the user. Else
there would be a feeling of inconsistency -- The system seems to 
erratically choose from different libs. I already found the m4/newlib
ambiguity no fun at all.

---<)kaimartin(>---
-- 
Kai-Martin Knaak
Email: kmk@xxxxxxxxxxxxxxx
Ãffentlicher PGP-SchlÃssel:
http://pool.sks-keyservers.net:11371/pks/lookup?search=0x6C0B9F53



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