delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2013/09/10/04:29:29

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
Date: Tue, 10 Sep 2013 10:40:55 +0200 (CEST)
X-X-Sender: igor2 AT igor2priv
To: geda-user AT delorie DOT com
X-Debug: to=geda-user AT delorie DOT com from="gedau AT igor2 DOT repo DOT hu"
From: gedau AT igor2 DOT repo DOT hu
Subject: Re: [geda-user] [RFC] Major changes to symbol/schematic libraries
in geda-gaf
In-Reply-To: <4522f5d733a99b250d8ba670a3abae14@mail.theimps.com>
Message-ID: <alpine.DEB.2.00.1309101013560.30022@igor2priv>
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> <4522f5d733a99b250d8ba670a3abae14 AT mail DOT theimps DOT com>
User-Agent: Alpine 2.00 (DEB 1167 2008-08-23)
MIME-Version: 1.0
Reply-To: geda-user AT delorie DOT com
Errors-To: nobody AT delorie DOT com
X-Mailing-List: geda-user AT delorie DOT com
X-Unsubscribes-To: listserv AT delorie DOT com

Hello all,

On Tue, 10 Sep 2013, Peter TB Brett wrote:

> On Tue, 10 Sep 2013 06:29:43 +0100, Peter TB Brett <peter AT peter-b DOT co DOT uk>
> 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 follow up with a few further points in another e-mail.
>
> On library masking (i.e. the question of whether a user library should mask
> a system library) there are few things to think about.  Let's have a system
> library A and a user library B, which both of which have an on-disk name of
> "xylophone".  For the sake of clarity, let's also assume that there's a
> design cache that Just Works.
>
> - A's library.conf advertises gschem symbols and PCB footprints.  B's
> advertises symbols only.  Does the "xylophone" library contain symbols,
> footprints or both?  What does the library selection UI show the user?

I am not sure I fully understand this. Is the situation that we have a 
symbol in A and a symbol in B which define the same thing (symbol name 
match or whatever mechanism is required for this)? Is the question whether 
in this case B should override A as a file, or attrbiutes merged? If so, 
both choice looks useful.

Merging on attribute level may pose risks: if a new attribute is 
introduced in A in a later point in time, would that propagate into my 
older schematics when I next open it? Or is this something the cache would 
solve?

I believe in eaither case some UI will be needed - the user needs to know 
why he sees what he sees. If merge happens on attribute level, the UI 
needs to be on that level, telling which attribute is coming from where 
and why. If it happens on symbol (file) level, you just need to know where 
the symbol is coming from, which might be easier to follow.

>
> - A's library.conf contains a title of "Marimbas" and B's library.conf
> contains a title of "Celeste".  What does the library selection UI show the
> user?
>
> - If I'm reading the comments so far correctly, the primary reason for
> wanting libraries to aggregate rather than mask is to abuse them as a
> per-project design cache.  If there's a design cache that Just Works, does
> it actually make better sense to mask than aggregate, from the point of
> view of making a UI that's comprehensible to users?

I think I see these differently. I don't fully understand your questions 
so can't directly map my model to them, but I can explain my use case or 
preferred workflow.

1. I'd have different libraries installed. Some might be system libraries, 
some might be library for porject groups or even for a single project. The 
system shouldn't know about the purpose, however, only the list of 
libraries. Basically libraries would aggregate on file (symbol) level. If 
there are multiple symbols of the same name, something must happen, but 
my preferenc on this largely depends on other choices (regarding to the 
cache). For example if symbols are embedded by default, I'd say symbol 
names should be path-like "library/name" combos, because I want to be able 
to pick from the full list. If symbols are not embedded, I might want to 
exploit the library system to change symbols under the project to some 
extent by selecting which of the libraries offering the same symbols 
should be used, thus it's better to refer symbols by name. It could be 
something like $PATH of a UNIX shell.

2. I have a script called devmap; this solves the heavy vs. light symbol 
and the transistor problems for me. It maps pinouts between the symbol and 
the footprint. My most common use case here is that I have a database of 
parts, each part is a specific device in a specific package. The part file 
is sort of a symbol patch altering existing attributes and introducing new 
atributes. The script is a wrapper around gsch2pcb that does this patching 
on the fly. On the schematics I have a generic (light) symbol with a 
reference to the part file. Part file name, by convention, is 
device_footprint so if this attrib is visible on the schematics, it makes 
it readable right away. I'd like to keep this mechanism working with a new 
cache or library system.

3. since I prefer to have multiple libraries, at the end it's difficult to 
"distribute" my schematics. I am fully aware of the features and scripts 
out there for embedding symbols, but I often forget to run them. In the 
normal workflow I have my schematics in svn, edit them, commit them often, 
and provide the svn url for others. In this workflow, I'd need to:
  - run an embedding script before each commit to make sure the schematics
    is self-contained and usable for everyone; or
  - I'd need to roll sort of a release where this happens, but this way
    others can't join the development easily; or
  - everyone needs to reproduce my library setup - getting all libraries my
    schematics depend on - and then a fresh svn checkout just works,
    without embedding; this is a lot of extra efforts, especially keeping
    the libs up to date.
The ultimate solution for this (at least for me) would be to make it a 
property of the schematics whether symbols are automatically embedded.

4. I can not remember making any modification to any of my symbols in my 
libs, because such a change could break my existing schematics, and I am 
too lazy to check them all after such a mod. Instead, if I figured a 
symbol would be better in a different way, I always cloned it. This means 
I could not make benefit of non-embedded symbols anyway.


Best regards,

Tibor Palinkas

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019