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

[Levente <leventelist@xxxxxxxxx>]

Why don't we simply write a script, that will collect all the symbols used in
a schematic file, copies it to the local directory, and we're done. Everything
would remain compatible, and you had all your things in your project
directory.

I think gEDA does not have a concept of a "project", but with unix tools
(make, sh, etc.), we can create one. A local gafrc helps a lot too.

I think that is what Unix is about.

For my "project concept" implementation, please go to this page:

http://levente.obudanet.hu/cgi-bin/viewvc/viewvc.cgi/pskel/

Levente

Peter TB Brett <peter@xxxxxxxxxxxxx> wrote:
> [-- multipart/signed, encoding 7bit, 1 lines --]
> 
>    [-- text/plain, encoding quoted-printable, charset: iso-8859-1, 129 lines --]
> 
> 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.
> 
> My primary motive is to make it easy -- no, trivial -- to share schematics & 
> symbols with other users.
> 
> 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.
> 
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> Proposed model: All the symbols can be found & used without any knowledge of 
> the libgeda library model whatsoever.
> 
> 
> 
> I have more, but I'm sure you get the gist, and it's getting very late here.
> 
>                               Peter
> 
>    [-- application/pgp-signature, encoding 7bit, 8 lines, name: signature.asc --]
>    [-- Description: This is a digitally signed message part. --]
> 
> [-- text/plain, encoding 7bit, charset: us-ascii, 7 lines --]
> 
> 
> 
> _______________________________________________
> geda-user mailing list
> geda-user@xxxxxxxxxxxxxx
> http://www.seul.org/cgi-bin/mailman/listinfo/geda-user
> 

-- 
Levente
http://web.interware.hu/lekovacs



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