Mail Archives: geda-user/2013/09/10/04:29:29
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 -