I like this idea --
you could have this combined with visibility to handle different styles of doing
things and backwards compatibility.
For instance, a transistor with pinname=g, pinname=d, pinname=s could be placed
and without more attribs it would only show pinnames, no numbers yet. Then
attach something about a package, and if that package has slots, slot attribs
would come with it.
Maybe this attribute group would be a symbol also, but one with a usually
invisible outline and attribs, that you pick from your library and place over
the generic transistor symbol? Perhaps pins could be given a new function such
that they get pin number info from the linked on attribute group and display
the pin numbers at the location of the pins at the location of some position
placeholder attrib like pinnumberloc. All those attribs in the packageless
symbol would be set to pinnumberloc=x. All the pins could have value x, which
has no information except its position, and is the place to display pinnumbers
gotten from a future added package attribute group
this concept is like a ultralight symbol with heavy information added in a way
that has no graphics. We could develop a text processing way to create these
heavy linked-on attribute groups, and save them in gschem libraries just like
the ultralights and the light and heavy symbols we use now. (Most of us create
all our own heavy symbols -- none in the libraries.
Having support for a new heavy-but-non-graphical attribute-group-symbol seems
like it might allow more easy churning them out and so available for libraries
for heavy symbols demand like for newbies to be able to use a workflow developed
by others and be productive without as much from scratch.
And, of course libraries of heavy-but-non-graphical attribute-group-symbols
would be antoher gedaconsulting.com fixed price bid item to describe and ask to
be paid for making...
It also segments tasks of symbol creation similarly to how your mind recognizes
the parts of symbols -- so it might allow automation of symbol creation from
OCR'd, (scanned and recognized), datasheet information.
John G
DJ Delorie wrote:
I wish I could show something more concrete but for now I can only do
some handwaving while I try to piece together exactly what I think I
need.
How about this idea: gschem symbols always have SYMBOLIC pin names,
and there's some magic that assigns slots and pinouts when mapping
them to footprints?
_______________________________________________
geda-dev mailing list
[email protected]
http://www.seul.org/cgi-bin/mailman/listinfo/geda-dev
