kicad-developers team mailing list archive
-
kicad-developers team
-
Mailing list archive
-
Message #39682
Re: Idea: Merging libraries along the search path
I like this, though if the UI is not made carefully it has the potential to
be confusing.
On Mon, Mar 11, 2019 at 10:13 AM Simon Richter <Simon.Richter@xxxxxxxxxx>
wrote:
> Hi,
>
> since the topic of library management came up: Would it make sense to
> collect library contents along the library search path?
>
> The search path would always be
>
> - project libraries (stored in the project folder)
> - user libraries (stored in the user home)
> - organization libraries
> - distributor libraries
> - upstream libraries
>
> The last three are pretty much optional, and would be just tags on the
> existing search path configuration.
>
> Rules:
>
> - The contents of each library is determined by scanning the full path
> and merging the entries in all the libraries with the same name.
>
> - All parts used in a project are copied to the project.
>
> - The editor saves to user or organization paths, and doesn't ask if no
> organization exists.
>
> - Parts altered by selecting "edit" on an instance should prompt for a
> name change, and are saved to the project and optionally also to
> user/organization.
>
> - Selection allows filtering by source tag (making shadowed parts
> available)
>
> This would solve the problem where users modify parts from shipped
> libraries and cannot save back because they are read-only and would also
> ensure that projects contain all parts required (so we don't have to
> embed them into the files). We could also display parts in the project
> and user libraries more prominently, giving users quick access to parts
> they use often.
>
> Would that make sense?
>
> Simon
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help : https://help.launchpad.net/ListHelp
>
References