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 _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp