Re: gEDA-user: Solving the light/heavy symbol problem

[DJ Delorie <dj@xxxxxxxxxxx>]

> But a database of packets might look different from a database
> that does the assignment of footprints, data sheets and meta 
> data by some other means.

Yes, but that's for the "how do we do it" phase.  At this point, if we
can agree that "hiearchical storage is good" and that we'd like to be
able to do both old-style, sym-meta-fp style, and "patcket" style
within this container format (or other way of collecting/defining a
library) that would be good enough for now.

This heirarchy could be as simple as our existing directory structure
(or url), or a more complex container format.  Functionality depends
more on how you manage the data's meanings, not how to manage the
data's bits.

But think of this... if we had a library that could contain varied
types of data (sym/meta/fp/url/text), one type being another library,
does your packet idea become one way of organizing the data in the
library?  Or is more needed?

> > Likewise, PCB has footprint variants you should be able to switch
> > between during layout, like RESC1608{M,N,L}.
> 
> The back-annotation problem remains. Is there any sensible way to do
> back-annotation with a hierarchy where a subsheet is used multiple 
> times?

I got halfway through typing "completely different problem" when I
realized how it's related.

The unrelated part: the netlister needs to give each element enough
information to identify the origin of it's element-specific metadata,
such that it's at least possible (with sufficient technology) to
update that origin.  This is a netlister problem, in that it must
"flatten" the heirarchy enough to realize the separate instances of
physical parts, and record that flattening in the element.

The related part is - what *is* the origin of that metadata?

Hmmm... as long as the netlister is consistent in flattening the
heirarchy, any element-specific data need not be back-annotated to the
schematic.  It need only be back-annotated to the netlister, so it can
merge that data with the schematic data to update the layout.  In this
case, the origin is the element itself.

For non-element-specific data (i.e. applies to all instances of the
heirarchy), I think the origin remains in the schematic, since pcb
doesn't understand heirarchy enough (or at all).

<future>

But that doesn't cover the potential case where pcb might support
hierarchical layouts (my powermeter is an example where that would
have been handy).  Same solution would work at least - send
hierarchy-specific data to the netlister, so it can apply it to the
whole heirarchy.

I think the general case of a heirarchical schematic with *one*
element having special data, being back-annoted to the *schematic*,
just isn't going to happen - there is no *one* symbol that's unique to
that data, in which to store it, at least if you use separate *.sch
files for blocks in the heirarchy.  Only if you view the *.sch by
navigating the heirarchy could gschem even hope to juggle all the
annotations enough to show you the "as-built".

</future>

> This seems complicated. Who would specify this URL?

Who "specifies" URLs for the Internet?

In this case, I think the URL comes from two parts - where the library
is (top-level at least) (which can be hidden from the user in the
chooser) and the location *within* the library, which is defined by
the library author, and corresponds to the tree we already show in the
chooser.


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