[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

Re: gEDA-user: RFC: Towards a better symbol/package pin-mapping strategy



John Doty wrote:
> Why are you hung up on the form the container of the information  
> takes? If the symbol file contains the same graphics, isn't that the  
> same symbol from a graphical point of view? Why do you consider it  
> different?
>   

I guess it's because I'm a control freak.  :)  I want it to be
convenient to dictate that "all NAND symbols will look like this", and
then if I change my mind, there's just one file to go edit to make them
look like something else.  That mentality prevents my NAND symbol for a
SOT6 chip from looking different from the 74LS00/DIP16 one, because the
same symbol data would be used for both.


> They represent topology. That's the *substance* (you cannot deduce  
> signal flow from a schematic without extra knowledge: that's part of  
> the reason DRC doesn't work very well). Now, use the native  
> capabilities of gEDA and your OS to create that substance, rather  
> than fighting them.
>   

I can see your point.  Maybe the problem that I'm complaining about is
that the standard set of gEDA symbols is just so small, that all those
personalized symbols that people are making aren't finding their way
back upstream, to prevent others from reinventing them.


> To me, they're topology. The same schematic imported into projects  
> with different symbol files thus may wind up representing different  
> wiring. That's part of the power of the project symbol approach.
>
> A directory full of symbols is a pretty decent database.
>   

Agreed.  Maybe I'm staying too focused on the small, trivial symbols
since those are the ones I have the most current experience with.

/me shrugs.


b.g.

-- 
Bill Gatliff
bgat@xxxxxxxxxxxxxxx




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