kicad-developers team mailing list archive
Mailing list archive
Re: Idea: Merging libraries along the search path
I like this, though if the UI is not made carefully it has the potential to
On Mon, Mar 11, 2019 at 10:13 AM Simon Richter <Simon.Richter@xxxxxxxxxx>
> 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.
> - 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
> - Selection allows filtering by source tag (making shadowed parts
> 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?
> 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