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

[Kai-Martin Knaak <kmk@xxxxxxxxxxxx>]

DJ Delorie wrote:

> We need to create a few small heavy symbol libraries.  These are the
> self-contained "starter" libraries we talked about.

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


> These libraries should be packaged such that it's easy for
> the user to replace the standard library with them, and immediately be
> productive.

This implies changes to the way gschem, gnetlist and PCB search for
libs. Currently, the only way to replace the default library is to
actually replace them at their original path (with root permission).


> gschem and pcb both need to be better at referencing multiple
> libraries of arbitrary depth.  This includes a better way to manage
> the libraries (gui, config, query rules), enable/disable them, and
> browse them.  This information should be sharable between tools,
> specifically, at least, between gschem, gnetlist, and pcb.

yes, please!


> While I do not wish to start a discussion about what kind of data
> should go in our "metadata", we need tools to work with it.  I think
> that breaks down to the following:
> 
> * On the database end, design an API or two with which we talk to the
>   data servers.  Implement a few servers to see how it works.  I've
>   started some ideas at http://www.delorie.com/pcb/component-dbs.html
>   at the "How is the database stored?" text.
> 
> * In gschem and pcb, we need a way to query the data servers in the
>   attribute editors, in order to suggest attributes.
> 
> * In gschem and pcb, be able to choose symbols/footprints based on
>   metadata queries - use the metadata as a filter for the library
>   dialog.
> 
> * gnetlist needs the most work.  It needs to be able to read a set of
>   rules, query the database, and fill in additional attributes based
>   on the rules.  This need not be more than just "fill in the blanks"
>   for now.

If we were to introduce the notion of packets, it would change the way
to look at the data. Without them, we'd have a symbol lib, a footprint 
lib, a bunch of other data and a web of relations in the database. Packets
are a way to represent the relations in an intuitive way. They partition 
the web of relations into, well, handy packets. 
In addition to the footprint lib and the symbol lib there would be a 
packet lib.
 
Packets would change the way gschem, gnetlist or PCB access objects. Rather
than query directly for footprints, symbols or meta data, they would ask the 
data base to pass the packet. Then they would evaluate the contents of the 
packet to suggest footprints, simulation models, or alternative symbols. 


> Gschem and pcb need a way to swap variants on symbols and footprints,
> for example, switching between resistor-1 and resistor-2, or RESC1608N
> and RESC1608M.  This depends on the metadata being available (above).

Did I mention, that packets provide a means for this kind of task?


> Modify gschem's symbol chooser to allow filtering based on attributes
> within the symbol, not just the symbol name.

The symbol chooser would morph into a packet chooser. This should 
be able to do filtering based on the contents of the packets. 


> Send a reply letting us know what you're working on,

I'll try to come up with a data format for a packet.

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