kicad-developers team mailing list archive

[Rene Pöschl <poeschlr@xxxxxxxxx>]

Hi again, I thought about it a bit more. I am less and less convinced this
will make it easier for users to understand the library setup overall.

But i understand where this comes from. After all many users say library
management is hard in kicad. (It is always listed as a downside when kicad
is compared to for example eagle.)

I am however not really convinced users mean "management" when they say
library management. (TlDr: they want it made easy to add assets anywhere
without needing to think about proper library organization. Your suggestion
would indeed help here. Details why i do not really like that are below.)

---

I think v5.1 adds a lot of powerful tools for proper centralized library
management. (the tree view is extremely powerful especially the right click
context menu.)  Please to not introduce new features that make these tools
no longer viable. (Make sure they are replaced with some that are as
powerful if you really must replace them.)
This also brings up the question how would you integrate merged parts into
the treeview. I think this will be one of the hardest things to decide with
your suggestion. (But maybe i am completely blind here.)

---

Right now kicad kind of favors a centralized library setup (the global
library) filled with generic footprints (and arguably generic symbols as
well.) I might be biased but this is a good thing in my opinion. (and i
would guess larger organizations would also like a tool that favors a
centralized library setup. Small organizations that do not have the
manpower to properly manage a centralized lib might in fact favor a project
central setup "managed" by every engineer.)

I think your suggestion in general would move kicad more towards project
specific libraries. (It will highly depend on the interface and the exact
implementation details.)
I would suggest that it is ensured that a centralized setup is as easy or
maybe even easier to handle than a distributed project local one.

This means it should always be possible to update assets in the central lib
and have these changes be pushed (with user interaction like it is now on
the pcb side of things) into old projects. It also means that it should be
easy to import assets into existing libs and it should also be easy to edit
the central library. (Unless it is write protected.) The later one is kind
of ensured if a single library asset is a single file.
For this to be fulfilled there must be an easy way to open the central
asset even if there is a conflict with a local one.

---

The current implementation of kicad kind of forces users to think about
their library setup in a way that eagle as an example does not. (I use
eagle as an example here as i am sadly forced to use it right now. So i
have a bit more insight into the differences between these two tools than i
would like to be honest. I also have an insight into what happens if you do
not have a central library management team made worse by the fact that
nobody in the company seems to really understand or care about proper
library management. You can say this is a bit of a culture shock for me in
particular.)

With eagle it is exceedingly easy to download a library (most likely
containing assets representing one component) and have it up and running
without needing to do anything in eagle itself (simply download to one
directory in the searchpath) On the surface this sounds like a great idea
right?

Sadly the fact that it is way harder to add an asset to an existing lib
results in users being at least tempted into having a directory full of
single component libs. (I would argue this is an unintended consequence of
making adding libs from the web easier than importing parts into an
existing library.)

Eagle makes it even worse as one can not link symbols to generic footprints
outside of the same library. Meaning i am also opposed to consolidating the
symbol and footprint libs into a single file (Not part of your suggestion
but lets put this out there as it fits the general theme of things. And
might even be kind of a logical conclusion if we take your suggestion too
far. After all if global libs are made harder to use compared to project
libs why would generic footprint libs make any sense?)

Why am i in favor of generic footprints? Well most components come in
standardized (JEDEC) packages. It makes sense to use standardized (IPC)
footprints for these.

---

The idea about copying the global assets into the project as a separate
local library is another thing that sounds good on the surface but again
comes with consequences. The problem with that is that you will most likely
end up with users being confused as the same asset now exists in multiple
libs. (The interface must be very well defined here. And very well
documented.)


Am Mo., 11. März 2019 um 16:13 Uhr schrieb Simon Richter <
Simon.Richter@xxxxxxxxxx>:

> 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
>