gEDA-dev: [PATCH] GAF: Solve the "transistor problem"

[John Doty]

On Aug 7, 2007, at 10:23 AM, DJ Delorie wrote:

>
>> That's the hard way.
>
> So?  We're designing electronics, not painting pictures.

The approach Bernd described sure sounded like painting pictures to  
me. The hard way.

>
>> The easy way is to copy the symbol to your project's symbol
>> directory with a new name, fix it up, leaving the pins where they
>> are, and then change the symbol name in the sch file with an
>> editor. Not hard at all. Maybe a little GUI magic over this kind of
>> process would help newbies, though.
>
> He's trying to do the gui magic :-)

I don't see the the project symbol library concept here at all.

>
> Me, I'd much rather have the pictoral symbol separate from the
> connectivity information.  We already split out the footprint, and
> it's way too much "heavy symbolism" to say we should have one symbol
> per package.

That makes sense, but I don't see that separation in Bernd's  
description. He's still thinking of the picture as representing some  
specific electrical thing. Maybe I don't quite understand his  
description.

>
>> This seems to represent a specific vision of how gEDA is to be used.
>
> Or at least how it *can* be used.  Today, nothing stops you from
> creating a heavy symbol library, but the technology stops you from
> creating a light symbol library.  Let's fix that so we can do both.

Eh? I think it's the opposite. A light symbol library is easy, and  
individual heavy symbols aren't hard. What's hard is creating the  
billions of symbols that a *comprehensive* heavy symbol library would  
need. I don't see that Bernd's approach really addresses that in any  
fundamental way. The symbols get to share a graphic, but somebody  
still has to track down, enter and check attributes somehow. That's  
the hard part of symbol creation anyway, especially for things like  
transistors and opamps where you already have a graphic to copy.

I see little advantage to sharing graphics in the current paradigm,  
as then changes in the library can break schematics: having a project  
copy is safer.

However, if you want to have a really flexible separation of graphics  
from attributes, I'll propose the following:

Embed all graphics in the schematic: the schematic is graphical, and  
you don't want to have it mutated when libraries change. Associate  
the symbol instance with a database key (instead of a symbol file  
name). Use the key to obtain attributes. Promote attributes from the  
database to the schematic as needed (but I think often I'd just want  
the refdes: use the database for the others, making up new keys as  
needed.

Attributes are not graphical, and an interface designed for drawing  
is a hard way to deal with them. Teasing them out of an "en" pileup  
is often a pain. I'd much rather deal with them as structured text.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd at noqsi.com