Message-ID: <522F5916.5070008@sbcglobal.net>
Date: Tue, 10 Sep 2013 10:38:30 -0700
From: Girvin Herr <girvin DOT herr AT sbcglobal DOT net>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/20130807 Thunderbird/17.0.8
MIME-Version: 1.0
To: geda-user AT delorie DOT com
Subject: Re: [geda-user] [RFC] Major changes to symbol/schematic libraries
 in geda-gaf
References: <87ob83dodl DOT fsf AT harrington DOT peter-b DOT co DOT uk> <87sixdi6rc DOT fsf AT harrington DOT peter-b DOT co DOT uk>
In-Reply-To: <87sixdi6rc.fsf@harrington.peter-b.co.uk>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: geda-user AT delorie DOT com

Peter et al,
I certainly hope that whatever you change, still transparently allows 
the use of the current (old) symbols in gschem.  If it does not, then 
that will break a ton of my schematics, which is not very friendly.  I 
tried embedding symbols in my schematics a while back, which was not 
entirely successful.  IIRC, it had to do with copying the embedded 
symbols.  As a result, all of my schematics reference my external 
library, which is populated with my own symbols as well as symbols 
copied from the standard gschem library and modified.  I would not be 
pleased if this connection were broken in 1.9.x and I get a slew of red 
triangles in my schematics.  In fact, by the standard software 
development versioning rules, if the API changes, the major version 
number should change.  i.e.  1.9.x should be 2.x.
Girvin Herr


On 09/09/2013 10:29 PM, Peter TB Brett wrote:
> Hi all,
>
> Rather than reply to all messages individually and fragment the
> discussion further, here are my thoughts on the feedback that I've
> received so far.
>
> - I'll add the ability to obtain a resource X that's located in the same
>    library as another resource Y.  If there's no X corresponding to Y,
>    the library will fail to resolve X (although a program might use a
>    fallback method that just looks up X normally).  This won't be used by
>    gschem, although other gEDA-related programs might want it.
>
> - "geda-gaf" is the XDG subdirectory used by the configuration system, so
>    the library system ought to use it too.  By convention, the XDG
>    subdirectory is the same as the name of the package, and the package
>    is called "geda-gaf".  If your scripting language cannot cope with the
>    character 0x2D, you need a new scripting language.  Let's not discuss
>    the colour of this particular bike shed any further.
>
> - Several people have mentioned the benefits of a project resource
>    cache.  I agree with almost all of the points made --- a project
>    resource cache is a great idea.  Let's have one.  But I'm fed up with
>    having things in gEDA that work "sort of".  If I'm designing a new
>    subsystem, I want it to work *properly*.  If we're going to have a
>    design cache, let's have a design cache that behaves like a cache,
>    looks like a cache to programs and provides an API that lets you carry
>    out cache-specific operations.  Let's *not* shoehorn it into the
>    library system by using special magically-name project libraries.
>    Would it help if I added some info to the wiki page on how I think
>    that a cache should work?
>
> I'll follow up with a few further points in another e-mail.
>
>                                 Peter
>