It’s much easier to put everything into one library than sort it out so do what you want but footprints sorted into libraries is something that many users (I think most of them) prefer and should be left (but improved).
Footprint names, descriptions, tags are not good enough (a lot of work to make it reasonable) so any search engine will have problems with them.
It’s not true that every footprint has one name. There are different standards (IEC, JEDEC, JEITA), names of some components like resisors, capacitors are quite often effect of authors fantasy.
Downloading one big library from github takes a lot of time.
It’s harder to improve libraries if they are not sorted out, now it more clear which libraries are good and which bad quality and it’s easier to make changes on groups of similar components.
Why not? If you look for a SOT-232 the search engine should pull it just fine even if it’s got other names
First of all you don’t have to download the whole “library”. You can just search for a component and then download it to you local library. If you want to get the whole repository, you just do it once. It is not the end of the world. This is not 90s. People download movies in HD quality and you don’t hear them complaning
Instead of improving libraries you will be improving a library. How is it harder. Instead of spending time trying to organize cumbersome hierarchy you will actually spend time improving footprints themselves.
Really?! How would you do that?
So far all I’ve heard sound more like: “this is how we do it and we like it that way” rather than trying to take a fresh look at the problem
[quote=“michal777, post:28, topic:952”]
Sorry if you don’t understand it.
[/quote] Seems that nobody else, among us mere mortals here, understands it. So far I haven’t heard a compelling argument that would make any sense. I wouldn’t qualify any of the reasons that you mentioned as good, since you were not even able to defend a single statement you made.
I am not sure how libraries are helping with the footprint issue that you are describing. The original issue of this thread, which I fully agree on, is that parts are sorted into libraries which is often not helping at all. If every footprint would be in a big folder, I would alt least know where to look - plus I could sort all footprints by name…
Yes, but Michal has already pointed out some of the issues with sorting by name. It really doesn’t matter; people can organize things however they want and use symbols etc. from whatever sources they want. Over the years a few people have even written their own software to manage things the way they like. Even if you visit various companies to see how they manage parts and so on, everybody has a different way of doing it. It doesn’t matter what scheme is implemented, most people won’t like it. If people want to use the KiCad github libraries but don’t like the organization, they can make their own changes to suit the way they work or propose changes to the current organization and demonstrate how those changes will be helpful. As is typical with these discussions there is a lot of criticism but no one seems interested in planning things and doing the work, so nothing happens. What is in KiCad’s github libraries at the moment is the result of many months of people negotiating protocols and actually spending time to ensure some consistency; if people don’t like it they should simply not use it or if they want to complain they should at least offer some useful advice and demonstrate how things can be improved.
Not to belabor the point but he didn’t. He just mentioned that: “Footprint names, descriptions, tags are not good enough”. When I pressed him on it, why exactly that is, he just avoided the answer. If you think about it, that is exactly how it is done right now. All footprints and symbols ARE being sorted by their name! Only you have to jump through all the hoops and navigate the maze so you could get to that point. Now if you add aliases and possibly other tags to the names it would make sorting and search functions only so much easier. Come On people! Databases have not been invented yesterday.
In case you skipped everything that a lot of users have written here, one useful advice for you, that was repeated over and over again - is to put everything in one folder (or library) and have a simple search engine.
And yes, the most popular cop out is that it is the way it is and the users can organize their libraries the way they want. Which does work if you make your own footprints and symbols, never need to have them updated and never need to get any new ones, which is a pretty preposterous assumption. I do have my own library but every time I’m missing a footprint or a symbol and I go and check if I can find it in the standard libraries so I can avoid building it from scratch. I waste my time meandering trough confusing libraries, linking new ones, unlinking them. Usually it is faster to build it from scratch than try to find it in standard libraries.
Your stand on this problem is: “Well just keep building it yourself and stop complaining!” I happened to think that although KiCad is a freeware and we do appreciate all the work that developers put into it, there is still some room for improvement. The purpose of this thread was not just to vent and complain, but to offer a simple solution or as you called it a “useful advice” which doesn’t seem to be very useful to the developers present but seems to be pretty popular with the users.
if they want to complain they should at least offer some useful advice and demonstrate how things can be improved.
Well, as I see it, we are not really talking about libraries vs. no libraries here… the real issue is the component and footprint handling in KiCAD. It does not really matter how it is realised if it just would be more intuitive. The problem is that dealing with components, footprints and the coupling of both is basically one of the main tasks when developing electronics. So as a result this needs to be usable intuitively otherwise the whole workflow is stuttery and often a pain (just my 2 cents). So please excuse if the following issues are sometimes not really related to the question “libraries or no libraries”.
Here are some major points I am experiencing over and over again when working with KiCAD that might already help a lot to improve the whole experience:
Library management (or folder management if you like). It took me a couple of hours to understand how to link in a new library and what was the difference between the legacy ones and the new ones. Why can’t I simply browse to a library to add it?
Search in CvPCB. This is a big one! Assigning footprints to the schematic is always a pain with KiCAD. Why can’t I search for “SOT-23” (or just for “SOT”) when I need this footprint? Why do I have to go through the libraries and scroll through them to find the footprint I am looking for? It really feels like crawling on my knees to get to the footprint I want.
Searching footprints is amazingly slow in PcbNew.
Multipart components can be a little bit irritating in EeSchema. One needs to know that you need to go back to the component selection to add the next module. And how should a user know that the power-section doesn’t need to be added at all (if the power net-names are the same… if not, what to do then?)? It would be so much easier if there were a simple context menu that would be available by simply right clicking on one of the already placed sub-components. Available actions could be “Add next sub-component” if there were any left… And please add the power-section as a sub component! I want to be able to connect my 12V to the power input of my opamp no matter what this pin is named!!
These are the main things I can think of at the moment. I hope there are enough improvement suggestions in there.
The library management is a big nuisance, especially if you are moving to a newer file format. There have been some discussions but no great solutions so everyone has worked on their own modules of expertise and little has been done regarding migrating projects to the newer formats. As far as the organization of files and the quality of the submissions, there are many volunteers working on this and the work is entirely independent of what the developers are doing with KiCad. In fact not long ago there were some frustrated developers because the library volunteers had made some changes to improve things but the devs didn’t know and some of their projects were adversely affected. The project is still waiting for someone to come up with a brilliant solution to control such problems in the future, especially with regards to the github libraries since many people actually use them online.
Don’t worry about cvpcb; it is deprecated and will disappear entirely in the near future. With some luck it may even disappear before the stable release.
Searching footprints in pcbnew can be extremely slow if you’re using the online libraries. I’ve never had problems searching for files on the local drive. Once again, various solutions have been discussed but nothing done (someone with the skills needs to implement a solution). At least some users have provided some patches in the past year which have made the process far less painful than it was before.
Multipart components can be very frustrating; I wouldn’t be surprised if there are still quite a few bugs in the code. However, nothing will be done until the Great Overhaul of eeschema. Like many of the problems users face, this one is yet another which is a matter of resources. Almost all of us contributors can only work on the project in our spare time, which typically isn’t much, so progress can be incredibly slow.
I can’t comment on the power pin assignment of modules since I can’t remember much about the topic. Perhaps the library contributors can offer some insights if you post to the library list.
I have plans for a part manager to make life easier, but given my other commitments I don’t expect to make much progress until 3 years from now.
It can be but it shouldn’t be. The next point might seem overly simplistic but I think it is still applicable. I just went to Google and ran a search for the word “KiCad”. I got 423000 results in 0.31 seconds. A natural response would be that we don’t have Google’s resources to crunch through so much data. Well first, with component library search, you wouldn’t have to deal with billions of records. And second, who is to say that you can’t setup a database and use the same Google to search through it? Come up with a user friendly GUI so all this happens in the background and is transparent for the user. Yes it would require changing a lot of things in the way things are done right now and being able to take a fresh new look at the old problem.
If it disappears but the component management algorithm remains the same, then not much really would change.
I guess that “databases” are indeed the fastest way to retrieve search results. The actual components or footprints should not be stored in the database itself though. I think the key to fast search results was up to day and will be later on as well - “indexing”. So if the components & footprints are simple files, KiCAD would need to run an indexing-job on the available files (regularly or via tracking changes in the library folder / URL). I am not too familiar with how indexing works but I am sure there is some information or even open-source code out there.
As long as KiCAD then used the indexing information as its search-basis and not started scanning folders and remote ULR every time one searches something, it would be as fast as it gets.
I’ve been hoping for a “parametric” capability in addition to (or instead of) libraries. Even a simple text-based input, something like this: “PG1 40x75x300x4x2 PG2 100x100(0,0) PG3 50r25h(300,0)”
Breaking that down:
PGx = Pin Groups (unique pin characteristics.)
40x75x300x4x2 = 40x75mil pads, 300 mil apart, 4 per side, 2 sides.
100x100(0,0) = 100mil square pad at the center.
50r25h(300,0) = 50mil pad, 25mil hole, at location 300,0.