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: 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 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed 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 Precedence: bulk Hello all, On Tue, 10 Sep 2013, Peter TB Brett wrote: > On Tue, 10 Sep 2013 06:29:43 +0100, 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 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