delorie.com/archives/browse.cgi   search  
Mail Archives: geda-user/2013/09/11/01:21:01

X-Authentication-Warning: delorie.com: mail set sender to geda-user-bounces using -f
X-Recipient: geda-user AT delorie DOT com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20120113;
h=mime-version:in-reply-to:references:date:message-id:subject:from:to
:content-type;
bh=I33rjIJk2CaN2h7vOtOclSngx06ufQ8Eg3+COHB3Gs4=;
b=QCbpjUjcjHZLWsL7RKdnoBr1bGI6gNGfCAEVeJ/0Ntd2taPqgbBLSaBpcNdoTtDpGm
ztKXdhdiJHBHKuILhBzAW5CV+WJ+zt8CcWZHOb82nqlkPQ23lQpRV3RvGLb6G2K/sabK
okjiRSz15YguaJ2hamKyiF/TumQqczV1j/4h6Zxy4ibJAxawn16oIqq9jGJUPR7Wwz6U
N8vBv2cCvNWeSHqSg986p16m4Q6Dds88MxsoPhpiyc9i8ZKDV1dmgRBs+X7YQwUx0l2p
V+1d6UnLxGQzlAhIfqgF56+/GqPr0iW9eUFw649MW8pJmtwg28KaR3uYKeF9lso5Doja
L+PQ==
MIME-Version: 1.0
X-Received: by 10.220.181.136 with SMTP id by8mr26872161vcb.11.1378876832429;
Tue, 10 Sep 2013 22:20:32 -0700 (PDT)
In-Reply-To: <4522f5d733a99b250d8ba670a3abae14@mail.theimps.com>
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>
Date: Wed, 11 Sep 2013 09:20:32 +0400
Message-ID: <CAMvDHVDuJ7nG9kJLVSFx1NasRUVq4crVY3-uJvGrNxozqe7uhg@mail.gmail.com>
Subject: Re: [geda-user] [RFC] Major changes to symbol/schematic libraries in geda-gaf
From: Vladimir Zhbanov <vzhbanov AT gmail DOT com>
To: geda-user AT delorie DOT com
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

2013/9/10, Peter TB Brett <peter AT peter-b DOT co DOT uk>:
...
> 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?
>
> - 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?
>
> Overall, I do genuinely believe that masking rather than aggregating allows
> for a much more intuitive library management user interface.
>
> A final point: I have been toying with the idea of allowing the file format
> to specify resources in the form "<library_name>/<resource_name" in
> addition to the current "<resource_name>" format.  Obviously, this breaks
> the "abuse a library as a design cache" workflow, but on the other hand it
> provides the *massive* benefit that when a user adds a library, all of the
> resources in that library are actually usable without having to figure out
> what's happening in the other enabled libraries.  It also means that the
> order in which a user adds libraries to a project stops being significant.


I like this idea. It allows us to eliminate masking at all and use
multiple libraries with conflicting so far symbol names. System
and user libraries should not conflict any more if we will use
different names for them. If they conflict, we can just print a
warning. To solve the issue with breaking the old workflow we
could provide some migration instructions how to convert a local
library into a design cache and force gschem to use symbols from
the design cache if it will find in a schematic some entries
having no library name.

- Raw text -


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