Re: gEDA-user: multi-part symbol support

[Kai-Martin Knaak <kmk@xxxxxxxxxxxxxxx>]

On Tue, 28 Jul 2009 15:16:26 -0600, John Doty wrote:

>> It  would make a *.sch file even
>> less selfcontained.
> 
> Well, I don't think of .sch files as self contained anyway.

Others do. Different work-flows ...


>> So the information should be included in the schematic.
> 
> That's a potential barrier to reuse.

Not, if the information is included via embedded symbols.
(Yes, I know, you don't like embedding)
 

>> Require, that every attribute is unique within the set of symbols with
>> the same refdes.
> 
> Breaks the current usage of source=. 

No. 
Attribute unification applies to the internal netlist after subsheet 
symbols have been resolved to whatever the subsheet contains.


> Might break custom flows, too.

Hardly.
Current gnetlist already returns exactly one value for every attribute of 
a set of symbols with the same refdes. If more than one part of a multi 
part symbol contains the same attribute, gnetlist simply picks the first.
The supposed requirement only removes the current uncertainty which 
attribute will be returned.


> Well, that whole approach is incompatible with schematic reuse, at least
> the way I do it.

You can do everything exactly as you do now if you don't use list_of 
attributes. Even if you do, the proposed changes don't affect the 
schematic at all. It affects the symbols.


> In most cases it's more sensible to put the footprint
> in the project symbol, not attach it in the schematic.

I don't propose to attach the footprint, or any other attribute anywhere 
else than to the symbols.

 
>> What would be a sensible syntax for lists of values?
> 
> Scheme syntax. 

scheme syntax in attribute values <frowns>


> the back end can trivially parse this with (read) without
> evaluation from a string port.

And it will act in an intransparent, user unfriendly way in case of 
errors. Just like gschem already does, when it runs into problems with 
the config files. Silently failing to read the rest of the file made me e 
scratch at my head more than once. Generalized syntax comes at a price.
 
> I see little harm here.

:-)

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