Re: gEDA-user: Symbol embedding by default - with case studies

[John Doty <jpd@xxxxxxxxxxxxx>]

On Oct 19, 2007, at 3:52 PM, Peter TB Brett wrote:

> On Friday 19 October 2007 21:32:12 Peter Clifton wrote:
>
>>> 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.
>
> Not to mention that non-libgeda applications literally can't load your
> schematic successfully, because they will not be able to determine  
> where to
> get the symbols from.

A command that could take a list of .sch files and track down syms,  
sources, and model files would be useful as input to a variety of  
scripts.

>
> My primary motive is to make it easy -- no, trivial -- to share  
> schematics &
> symbols with other users.

Embedding them makes it *hard*. A symbol file is usable elsewhere, an  
embedded symbol isn't.

>
> My secondary motive is to make it easier for non-libgeda  
> applications to
> generate & manipulate gEDA-format schematics.
>
> When criticizing my approach, please take into account the  
> following case
> studies:
>
>
> Case study 1
> ============
>
> Peter is developing a new device using gEDA, and want to use an  
> external
> layout contractor (who also uses gEDA & PCB).  Peter wants to  
> package up his
> schematic to send off to the contractor, but has several non- 
> standard system
> libraries as well as some project-specific symbols.
>
> Current model: Peter is an expert, so he is able to spend a few  
> hours and use
> some complicated shell scripts to hunt down every relevant symbol and
> organize them into a new directory before manually checking through  
> that the
> correct symbols have been selected and that nothing has been  
> broken. He then
> tars the assemblage up before sending it to the contractor.  The  
> contractor
> untars the files, and (if Peter was successful) can then use the  
> schematic.
>
> Proposed model: Peter sends his schematic file to the contractor.  The
> contractor double-clicks on it, and it opens in gschem in fully  
> editable and
> consistent glory.

Better model: Peter invokes a script, geda-collect-project, which  
collects all of a project's files (makefiles, gafrc, other custom scm  
files, models, Spice test files, etc.) and makes a tarball or some  
such, sends same to contractor. Contractor uses geda-expand-project  
to get the whole thing.

>
>
> Case study 2
> ============
>
> Peter is developing a new device using gEDA, and is looking for a  
> symbol for
> the LM7171 op-amp.  Having found one on a random website, he wants  
> to then
> use it in his schematic.
>
> Current model: Peter hacks his gafrc to define a project-specific  
> library,
> places his new symbol in the appropriate location (double-checking  
> that the
> name doesn't conflict with an existing symbol), and then hunts  
> through his
> library list to locate it.
>
> Proposed model: Peter clicks the "From file..." button in his symbol
> management window, selects the appropriate symbol file, and is  
> prompted for a
> symbol name.  Accepting the default, the symbol appears in his list  
> of active
> symbols, and is automatically selected for placement.  An icon next  
> to its
> list entry indicates that the symbol does not exist in any of the  
> active
> libraries, but because he only needs the symbol once in this  
> particular
> design, Peter doesn't worry about it.

But if gschem puts the symbol file into the project's symbol  
database, Peter can use it as many times as he wants. He can edit it  
(you almost always need to), copy it, etc. The UI idea is fine, but  
please don't embed.

>
>
> Case study 3
> ============
>
> Janet has been preparing a design using KTechLab, but finds that it  
> lacks some
> functionality that he can get using gEDA.  John decides that  
> KTechLab needs a
> gEDA schematic exporter.
>
> Current model: John's export filter has to generate project symbol  
> directories
> and configuration files in addition to the actual schematics, and  
> has to do
> gymnastics to make sure no conflicts occur with existing files.

Just import into a fresh directory?

>
> Proposed model: John can just output schematic files with the  
> necessary
> symbols embedded, and knows that the schematics will Just Work even  
> if there
> are symbol naming conflicts with the user's existing gEDA libraries.

Automatically merging an external project with a gEDA project seems  
unlikely. And that's the only case where you'd have trouble.

>
>
> Case study 4
> ============
>
> Having successfully completed a gEDA export filter, John decides to  
> tackle a
> gEDA import filter.
>
> Current model: John is screwed, because without converting KTechLab  
> to use the
> the whole of libgeda + Guile interpreter, he can't find the symbols  
> he needs.

As I said, need a command to do that. Shouln't be hard.

>
> Proposed model: All the symbols can be found & used without any  
> knowledge of
> the libgeda library model whatsoever.

Symbols are only part of the problem. But a way to identify all of  
the files a project uses could lead to a much more general capability.

John Doty              Noqsi Aerospace, Ltd.
http://www.noqsi.com/
jpd@xxxxxxxxx




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