kicad-developers team mailing list archive

[Carsten Schoenert <c.schoenert@xxxxxxxxxxx>]

Hello Wayne,

Am 22.06.2018 um 15:42 schrieb Wayne Stambaugh:
> This is a potential solution.  There is no limit to how many library
> tables that can be chained.  I see several issues with this solution.
> 
> Users who track the development libraries will have most likely fully
> duplicate tables in there user config which could slow down the
> footprint lookup and browsing although it would be minimal.

yes, for sure. OTOH I guess such people are not the typical users and
know what they are doing. But into a probably performance issue you can
run every time if you add a lot libraries sources, so I'm not sure this
is a really valid point in the end, it's part of the problem.
We need a solution that is fault tolerance and keeps the adjustment
steps on the user side really low. I know persons which even don't use
4.x because they need a working solution and don't have time to migrate
their old projects into 4.x.

> Given our history of not getting the default install path correct,
> finding the default library tables could be problematic.

But would it not be better to rethink it all and create a future safe
solution for upcoming KiCad versions then? I know that will not be
simply, otherwise it be already reality. How about adding such a goal to
v6 (or to some 5.x major update)?
First the wanted solution needs to evolve, then a needed migration algo
should be added.

1. Which real advantages has (or should have) the fp-lib-table in the
   users controlled directory if there are from the packaging controlled
   libraries be controlled?
2. Should not only globally to be used footprint libraries added here
   (from a per user perspective)?
3. What if the file would be dropped and all is controlled within the
   KiCad project? Which can provoke issues if the project is used on
   a completely different environment (aka pc and user/os, Kicad
   version). But this can also happen with a different fp-lib-table file
   too.

A few weeks ago I was thinking about packaging the DigiKey symbols and
footprints and that's a rather easy task. But it's really difficult that
users can add such libraries, they need to add every one manually.
Providing a package which isn't really easy to use for Kicad users is
then just a waste of time of both sides.

https://lists.launchpad.net/kicad-developers/msg35970.html

That problem goes right into the discussed issue here. KiCad is far away
from making it (power) users really easy to add third party addons. The
"professional" software is mostly doing here a better job.

> Changing a symbol library table could lead to missing and/or broken
> symbols which causes it's own set of issues.
> 
> Changing a footprint library table could result in unexpected footprints
> being pulled into a board.

Agreed, so they should only be changed if it's really needed. I think
it's better to compute such lists in real time and dynamically than to
use static files which users (or external tools) can be modify in a way
they are not valid anymore.

The KiCad project needs some automatic testing based on the Python API
so no human interaction is needed for doing them. The libraries people
already have mentioned some simply formatting change back and forward in
the project files which had happen sometimes but can make a git diff
really unreadable do the amount of time to control.
Unfortunately I can't really help here.

-- 
Regards
Carsten Schoenert