← Back to team overview

kicad-developers team 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
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