Re: gEDA-user: multi-part symbol support

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

On Mon, 27 Jul 2009 11:36:53 -0600, John P. Doty wrote:

> Anything that goes into a BOM, for example. That's an open ended list,

ack. 


> A one-shot solution for each attribute won't work. 

ack. 


> Nor, I think, is it right to do
> this for all attributes, as "source" is potentially properly multiple,
> and we shouldn't preclude other such attributes.

Almost all attributes should be made unique with regard to the refdes. 
Therefore it is better to define a set exceptions. The information which 
attributes are exceptions must reside somewhere. Hard coded into the 
source is clearly no good option. Somewhere in the config files is an 
invitation for inconsistency problems. It  would make a *.sch file even 
less selfcontained. You'd have to always ship a gnetrc along with 
schematic file. 

So the information should be included in the schematic. It would be 
possible to read gnetlist options from global attributes of the schematic 
or from attributes of the title page. However, I'd be wary to introduce 
yet another way to pass options to gaf applications. 

But how about this: 

Require, that every attribute is unique within the set of symbols with 
the same refdes. But add the notion of lists as values of an attribute. 
Instead of multiple attributes there would be multiple values of an 
attribute. As an aside, this would resolve possible ambiguity about the 
priority of attributes. A list is ordered in an intuitive way. An 
additional benefit is, that the multiple values cannot be scattered over 
multiple symbols. This reduces the chance of confusion.
 
Value lists would come handy with my other most wanted gschem feature, 
too: Present a selection of reasonable footprints in the attribute editor 
of gschem. The list of reasonable footprints should be a property of the 
symbol and it should be adapted to the preferences of the site or 
project. 

What would be a sensible syntax for lists of values? 
The attribute name should contain the information, that the attribute can 
contain a list. Else, simple string values might be misinterpreted to be 
lists. An intuitive way to mark an attribute as a list would be to 
require "list_of_" at the start of the name. List items might be 
separated by semicolons.

Bottom line: I propose to make every attribute in a set of multi part 
symbols unique during gnetlist runs. If more than one value of a 
attribute is required for some purpose, this can be achieved with a list 
of values.

Do you see a flaw in this approach?

---<(kaimartin)>---
-- 
Kai-Martin Knaak
Öffentlicher PGP-Schlüssel:
http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x6C0B9F53



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