Re: gEDA-user: gschem, More than one component found with name ...

[Peter Clifton <pcjc2@xxxxxxxxx>]

On Fri, 2007-10-19 at 14:12 -0600, John Doty wrote:
> On Oct 19, 2007, at 11:00 AM, Peter TB Brett wrote:

> > The intention is to provide a straightforward but powerful GUI for  
> > keeping
> > schematic & library up to date.  There would be a list of all symbols
> > currently embedded in the schematic, showing how many times each  
> > has been
> > instantiated.
> 
> What schematic? File != schematic.

Which is exactly the problem in many cases, your foo.sch file is not
enough to share, or move into a different project, you have a whole
array of other symbol files which are explicitly required along with it.

I'm not necessarily suggesting that we must make entire designs fit in
one file, but saving a cached copy of symbols used along with a .sch
file (in the file) will help schematic reuse.

> > Symbols which differ from that found in the library would be  
> > flagged with an
> > icon, indicating whether the library symbol is newer or older than the
> > embedded version.
> 
> What library? We don't even yet have the most crucial thing: the  
> project library concept. So we all implement it in ad hoc ways,  
> because the symbols in the distributed library are usually wrong for  
> any specific purpose. So, you copy, customize, and then updates of  
> the distributed library are irrelevant: your project library has what  
> you need.

We have a project library if you set one up in your gafrc, but that
means you have another file required to open the schematic page and find
the symbols, and that must be merged if you want to re-use a page in a
different project.

More explicitly... we don't have a concept of _project_ in gschem.
(Hence the problem requiring these extra files).

> > It would be possible to select all instances of a symbol, so that  
> > users can
> > see which symbols would be affected by an update.  Clicking an  
> > "Update"
> > button would show the user a dialog with a preview the old and new  
> > symbols,
> > and a radio box to select which symbol to use.
> 
> Completely unnecessary with a project library.

Ok, so you're going to maintain a set of your own symbols per project,
rather than "globally" on the computer.

I'll assume there is some reuse, and perhaps you find a bug in a symbol.
Isn't updating your project library for each project is no easier than
updating embedded symbols in the schematic? You'll still have to go into
each project, update the symbol in that project library, and verify it
hasn't broken any of the schematics.

> > It would also be possible to "export" embedded symbols into a local  
> > library,
> 
> As far as I'm concerned, this should happen automatically. Both  
> embedded symbols and instantiations of distributed library symbols  
> are trouble waiting to happen. But a library of customized project  
> symbols is a valuable asset, analogous to a parts stock in drawers.

I wonder if we aren't all thinking along similar lines, but disagreeing
on whether the cache of the symbol in use should be in the schematic
file or a separate "database" along with the project?

> > and to rename embedded symbols without making any library changes.
> >
> > My viewpoint on all of this is that it currently seems that  
> > detailed knowledge
> > of the gschem library system is required in order to gschem &  
> > friends at all
> > effectively.  We are severely hampered in our ability to  
> > interoperate with
> > other libgeda tools due to this.  Some sort of sane self-contained  
> > file
> > format is not only desirable but *required*, and the current embedding
> > mechanism fails at this in an embarrassing fashion.
> 
> No! A self-contained file isn't reusable, while the present approach  
> allows .sch files to be used as components of multiple schematics.  
> Please, please, do not compromise gEDA's most valuable asset: its  
> flexibility.

Why would a file with caches of its used symbols be any less re-usable
than one which simply has symbol names in it? It should be _more_
re-usable. At least then, if you open it with a different library search
path, you won't get a load of missing symbol errors, you'll get some
more informative warning that the library part can't be found, and we're
using a cached version.


Best wishes,

Peter C.




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