Yeah, the user experience here could be improved.
As I have âsave a local copy toâ ticked and KISYSMOD etc local, it seems that my PC only fetches from online when I use the Wizard and not when I am just using KiCad
What version are you currently running now?
I may have to double check my KISYSMOD; I thought it was good at last check ( a while ago ).
I have a mixed bag of 4.0.6 and latest Nightlies, Ubuntu and Windows.
please forget that I asked.
Iâm not quite ready to go down that rabbit hole. I need a reasonably stable for the 2nd prototype board.
Different machines. I mostly use Nightly
KISYSMOD is always local.
But if there is no entry in the fp-lib-table that points to it then it does not change anything.
The problem is that at least the stable release on linux (fedora) uses github as standard setting. Not sure about current nightly on linux.
As long as it is the standard setting, the vast majority of casual users will never know that there are other options and therefor use the github plugin.
For anyone who wants to have a local setup i would suggest to follow the tutorial by @bobc.
Are the developers against changing this sort of stuff because they feel the resources are spend better on other projects or are they really against changing it because they have written it?
I canât imagine it is the later. (I hope it is not. It would mean they are not prepared to learn.)
I personally canât look at code i have written a few month ago without cringing. There is always something that could be done better. Most of the time it is a lazy design decision that i dislike later on.
The reliance on the github api is a clear problem. A much better solution would be to use a full git plugin. This would give the users much more options. (I think @SchrodingersGat has already tried to suggest that to the developers.)
1 Like
The feedback I get from the core devs is as follows (paraphrased).
A new library system is welcomed, but it must not break compatibility for users who use the GitHub plugin.
I think there are people too attached to the code, unfortunately.
I have suggested (at extreme length) possible workarounds, each (IMO) kneecapped by this requirement to keep the GitHub API thingy.
I would like to see the libraries availble for download (as stable releases) on the website. This could be as simple as a link e.g. to Latest Released Library.
âAdvancedâ users could still keep their libraries up to date using Git - any plugin we write using a git interface will need a lot of work to even approach the functionality of your most basic git client. Why waste that effort when itâs already there?
TL;DR - the âbestâ options IMO would be to remove the github plugin and have a sensible way of distributing libraries that is independent of the software. The ânext bestâ would require a lot of coding and probably make things more difficult, at least in the short term.
Any thoughts? How do other EDA tools distribute libraries? It has been a long time since I used anything besides KiCad
It seems like either:
Current library code can be used as a backup for finding components, or
New/old library code could be chosen with an option. The key would be identifying the library API within the code and create the new functionality behind the same function calls. Then create similar calls that decide which library function call to use based on the option selected. More work, but saves compatibility as a choice and separates new code from old.
Eagle just distributes them with the software. No update button. (At least not in eagle 6. I have not played enough with eagle 7 to be sure about that.)
There is also a webside where users can share their libs it seems. (but i see no real organization of it. Just a bunch of libs in a long list with one sentence descriptions.
TlDr of my opinion: We donât really need to remove it. Just donât make it the standard.
The local lib setup is not bad in kicad. (updating is a bit cumbersome but well we could live with that.)
I think if the devs want better user experience with little effort, the only thing needed is to make the local setup the default setup and have an easy button that updates your local libs. (It just has to open the lib wizard starting on page 2.)
Why a dedicated update button? Well i fear most users will not get the idea to simply re run the lib wizard to update their lib. (They might not even get the idea that updating the lib can be done.)
Maybe rename it to footprint lib downloader? (Similar to the 3d shapes downloader.)
What would be nice is to have all libs in one repo though. I donât think the github plugin can handle that. Or can it? (Did you not mention that the devs donât want multiple repos for symbol libs? Might this be the way to get them interested?)
2 Likes
What would be nice is to have all libs in one repo though. I donât think the github plugin can handle that. Or can it? (Did you not mention that the devs donât want multiple repos for symbol libs? Might this be the way to get them interested?)
Youâre correct, all the .pretty directories in the same repo is a must-have update. However this is incompatible with the GitHub plugin (otherwise I would have done it already).
The GitHub plugin downloads each .pretty library as a .zip file, and it cannot download sub-directories (because of the GitHub API limitations). So to work with the plugin, each .pretty library has to be a top-level repo e.g.
github.com / kicad / repo-name
And yes, the devs at the same time do not want to split the .sweet libs into multiple repos. I have not been able to get a clear comment on how these two competing ideas will be resolved.
1 Like
Maybe using the code of the 3d lib downloader?
That performs really badly on my high latency from Asia Internet. The pause between each file is very obvious and fetching several directories can take an hour.
is there a reference i miss?
The 3d libs are huge compared to the expected size of all symbol libs. And remember you will not need to download them every day but only if you want new symbols. (or if you know a symbol in your lib version has a problem and you suspect it has been fixed already.) Otherwise we could use the current github plugin for the new symbol libs as well.
(Iâm not suggesting what would be best in the long run but how to get away with not using the github plugin and removing the last arguments for developers who do not like seeing this being replaced by something else.)