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

[Kai-Martin Knaak <kmk@xxxxxxxxxxxx>]

DJ Delorie wrote:

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

My proposal to tackle many of the library related issues is the notion
of packages. These would be data structures that can contain all information 
relevant to an entity us humans like to build electronics from. Specifically, 
they may contain
 * symbols  
 * footprints
 * simulation models
 * data sheets
 * acquisition information. 
 * comments
Note, the plural. Symbols may be alternative, or grouped. All content may 
be embedded or a link. Both have their specific strengths and it is up to
the designer of the lib to choose. There may even be a combined embedded 
and linked mode. Use a link as a reference but keep a local copy for 
fall-back. If the reference diverges from the local copy, ask the user 
what to do -- update or switch to pure embedded mode. 

To the environment, a package can be a file or an entry in a data base. 
In schematics and in layouts it may be referred to with a unique name, 
just like symbols are currently referred to. In addition, the entry in 
the schematic file would tell which of the symbols, footprints, or 
whatever this instance uses. There would be a GUI dialog to view the 
contents of a package and choose from them. Of course, it would also be 
possible to override and enter completely new for this instance only. 
Much like we can do now in the attribute editor.

Packages and pure symbols could be mixed transparently. Where and how to 
look for them would be configured in gafrc, just like we do now. So 
the fraction of data base lovers would be catered as well as those, 
who are in favor of files. They could use and share the same packages.

The notion of packages can be seen as a means to isolate dependencies. 
Pins in symbols must match pins in footprints. Simulation models are 
specific to components. Packages provide a way to keep comments, notes 
and all kinds of meta data attached.


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

There may be a "no defaults" mode on insertion of a package. If 
you want to set the specifics later, click on the symbol and choose.
How specific or a package is by default would be a design decision 
of the library author. 

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