The higher up you stay the bigger the downloads and the less sophisticated the interface.
The further down you go, the more sophisticated this has to be and most people probably don’t want to bother with a high level of granularity anyway…
Maybe I ask the wrong question though?!
That’s exactly the right question. Here’s what I envision.
Direct Download Option
Users navigate to the libraries website (e.g. kicad.org/libraries). This webpage has pre-compressed files containing complete library set. So, on the top level you have:
Download kicad_symbols.7z
Download kicad_footprints.7z
Download kicad_packages3d.7z
These are the “latest stable” and could be a bit “old” depending on how often they are updated.
We could also offer a secondary level, where it shows a list of libraries within each set. e…g
Download kicad_footprints/soic.7z
Download kicad_footprints/conn_usb.7z
(etc)
Git access
Git access stays as it is, and allows users to keep up to date with the most latest changes. This is also required for users wishing to contribute back to the libraries.
Simply as an example, here is how Eagle libs are distributed by Element14. An enumerated list of libraries that the user can select to download, giving them a sense of control and a warm glowing feeling inside.
This looks like a good idea. I like the idea of a library manager inside of KiCad - perhaps it would be selectable on the project screen much like calculator tools, and all the editors are. This would let people manage the libraries in a single spot, check which versions they want to download, and when they were last updated. This would also let people choose whether they want to have the 3D footprints updated. It means that the battle of local sources, git sources, or other networked sources might be easier to configure from within.
Since it came up at one point, what about managing libraries from KiCad with built-in git features? I don’t mean the current git http downloader, but a graphical interface to pull, commit, revert libraries. Ideally such a system could not only be used with github libs but also with my own git repository…
This is what I was previously investigating, using libgit.
But at this point, why not just use git? The amount of work required to write a new tool that could manage potential conflicts would be huge. And not all (many?) users would necessarily use git anyhow…
This is quite doable now at least with PCBnew. I agree that repository layout leaves much to be desired, but scripts do help. The eeSchema is a pain though. The default behavior of scanning libraries every time when opening existing project does cause issues when symbols in libraries change. You can put cache at the top of the library list, but you have to do this each time you create new project.
I can imagine that eeSchema could be patched to do this automatically on project create. But I doubt any dev would start with this since bigger changes are in schedule if I am informed correctly. The patch would:
make current rescue dialog redundant
would also make eeSchema and PCBnew act consistently on the same issue (PCBnew has internal cache and looks first in cache, then in the libraries)
would remove any issues with library consistency for old projects
At this point the most that can be done is to setup proper example and documentation for both approaches.
As for the future I can only agree with you
It makes no sense to implement and maintain new feature, that is freely available and maintained. It is not like there is a plethora of developers available for KiCad.
Can someone please do this? I do not feel knowledgeable enough to to write a quality bug report. At the moment my bug report title would be “KiCad Is a Data Hog”.
I do promise, that I will sign up and clicky the “this affects me too” button. I might even be willing to ship a box of cookies to the author; could be carbonated liquid hop cookies in a bottle or can maybe too.
Lets get this out there and make KiCad the change we want it to be!
A file ending in .7z is a compressed file created with the 7-Zip program. The compressed file can contain numerous files within it. Using 7-Zip to decompress the file will extract the individual files from the 7-Zip file.
If you look at the butracker replies, the developers did ‘hand this over’ to the windows package manager backyard.
So for a band-aid fix the windows installer ‘needs to find a way’ to separate the libs and the program installer, which as we know from own experience are in a sorry transitional-messy-kind of state right now, with all the different behaviors and philosophies.
I added my 2 cents worth to the windows package manager thread.
The true fix for this will be the change that @SchrodingersGat has been rooting for 12+ months now.
Don’t know if there is a bugtracker for that (should probably reside with the developer mailing list anyway), so yeah…
Here is a thought for the developers…when you bring up the list of components either 2d or 3d, just have the full list on the PC with the install, it could be updated upon loading of the program if you set a program option to check for updates (allow it to be turned off) if you select a component that you have not used yet, then just that components files will download. (and stay on your pc) this way you only will download what you need when you first need it, rather than downloading everything all the time. think of it sort of like the “Cache” in your web browser but completely persistent. If all software developers would think this way, a lot of unnecessary bandwidth could be freed up. Just a thought…
I downloaded a Windoze nightly a couple of days ago and have been playing around with it.
THANKS FOR THIS FIX!
It is really great to see a legitimate complaint get taken seriously and corrective action taken; especially since I know the “whole of it” was not trivial and required a massive amount of work to get done.