On Wednesday 19 December 2007 12:17:02 Levente wrote:
> Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
> > I still haven't been convinced by these arguments, especially since
> > _nothing_ you've described can't be implemented with symbols which are
> > embedded by default. (So there. :P )
>
> Ok, you might be right, but I think it is another issue. Yes, I confused
> the attributes in the symbol file, and the attributes attached by gschem,
> after placement. Sorry.
Yes, this is a tricky issue, which I need to think about some more.
> > My vision of how the database could work is as follows:
> >
> > - Each symbol (or part) has to be uniquely identified by a string, and
> > each database/website/directory gets queried in reverse order of being
> > added to the library. This is as currently.
> >
> > For databases, this could just be a concatenation of the database name
> > and some sort of unique identifier number. The unique identifier string
> > would be stored in the schematic file where the "symbol name" currently
> > is.
> >
> > This provides a way to store exactly which part was selected by the user
> > in a backwards-compatible manner.
>
> Yes, but I think we should copy the information coming from the database to
> have ability to read/process schematic off line, when there is no remote
> database seen. Or did I interpret something wrong?
That's called embedding. :) Without a file-format change, the only
non-ambiguous way of associating a symbol in the schematic with a symbol in
the library/database/whatever is to use the field in the component
specification reserved for the component name. (This has the added advantage
of reducing the amount of code that needs to be changed in gschem & libgeda).
Of course, a local cache might well be a sensible part of a usable backend...
The problem with promoting the attributes into the schematic by default is
that the user might mess with them. _Forcing_ the user to add the attributes
to override them is a good way to make sure that the user only messes with
the attributes from the database if he really means to.
> [snip]
>
> > If the user selects a part, the component to be updated will get
> > replaced with the new symbol from the backend.
> >
> > "Old-fashioned" backends such as flat-files probably couldn't support
> > the "compatible" mechanism, but it is possible to imagine that databases
> > could provide lists of compatible parts for the basic symbols such as
> > resistors, capacitors and diodes from the default libraries.
> >
> > One tricky problem will be how to update attributes. Database overrides
> > all? Or some other method?
>
> I think we should have some border between "Old-fashioned" symbols, light
> symbols to be made heavy, and heavy symbols already updated from the
> database. Then there will be no confusion.
Um... I think exactly the opposite. What you're suggesting would just make
the already-steep gschem learning curve even worse. I'm trying to find a way
to make it so that there is *one* unified part/symbol library that's
sufficiently powerful and flexible for people to do whatever arcane things
they like with it, while still being capable of being used in a simple way if
that's required. I honestly think this is achievable, and I hope you agree
with me that it's a worthwhile goal...
Peter
--
Peter Brett
Electronic Systems Engineer
Integral Informatics Ltd
Attachment:
signature.asc
Description: This is a digitally signed message part.
_______________________________________________ geda-user mailing list geda-user@xxxxxxxxxxxxxx http://www.seul.org/cgi-bin/mailman/listinfo/geda-user