I thought I’d toss this idea up here to get feed back before I actually make a real feature request on the repo.
IMO, Eescheema could really use a 'Place Basic Device" to go along with the “Place Power Port” button. Most of what people are doing on the schematic is putting down a few large semiconductor parts, IO, a few power rails and a ton of jellybean capacitors and resistors. I think it’s safe to say that probably 80-90% of the parts placed in schematics are bog standard R and C components.
The Place Power Port button is really useful - it means we don’t have to place a part, open up the Power accordion and start searching from there. Just click the Place Power Port button and you’re there.
But when you place plain R and C components, you’re still having to drill down into the part menu, scroll down to Device and then go through a long list of obscure parts to get to R or whatever. (This is especially offputting to newcomers to KiCad who have to spend a ton of time scrolling through the huge parts list, trying to figure out where a resistor is at. I recall I spent probably at least 15 minutes the first time I used KiCad. It did not give a good first impression.)
What I think should be added is is a Place Basic Device (or common device or part or whatever) button that operates similarly to Place Power Port. When you click it, it has a short list of the most commonly used parts. My suggestion would be [C, CP, D, D_Schottky, D_Zener, L, LED, POT, R]. This way you can just pull up the components that make up 90% of schematics quickly and without scrolling through accordion popups and long lists every time.
If the implementer is feeling their oats, the list could be editable so an individual user can add and remove parts from the quick list to fit their individual needs.
What do people think?
Edit - I wanted to add the idea that the best way to pick out the parts on this list would be to just go through GitHub, collect data on all the KiCad projects out there and sort out the 10 (or whatever) most commonly used schematic parts and used that as the default quick list.
Open Eeshcma, on the keyboard press the “a” key (release), then the “r” key (release), followed by the “enter” key.
Also, one can simply press the “Insert” key to add another item of the last part.
For changing parts, it is simple to hover the mouse cursor over a symbol already on the board, and press the “c” key.
If you absolutely must have a graphic to click, then I suggest creating a new library, name the library “0_Parts” and place the components that YOU personally want.
By that logic, we should get rid of the Place Power Port button then. You can just hit ‘a’, ‘gn’ to get a ground symbol or ‘a’, ‘5v’ to get a 5V power rail. Hell, most of the buttons in Eescheema could be eliminated and we could just tell people to use the hotkeys instead.
If we’re going by how often the average user will use a given feature, the GUI button for placing a not-connected flag (which also has a hotkey) is certainly going to be used far less than something like this.
The vast majority of users prefer a GUI interface. Especially new users and occasional users. If KiCad is going to expand the user base and encourage more users, there needs to be some thought given to industry standard GUI design principles. Matching the most commonly used user operations with a GUI element is definitely one of those.
I always wondered why this is there. Maybe in early versions power symbols really where something separate of other symbols. (Or the developers knew that the current implementation is just a hack and always planned to implement them in a better way but never got around to do it.)
I disagree here. I think everyone who uses any program for more than one project will learn the shortcuts. It is always a good idea to have a good gui for beginners though. (Maybe i am the exception here. I used vim until i discovered atom. I even thought about switching to emacs. F12 opens a fullscreen terminal on all of my systems.)
I’m not an expert at this, and sometimes I read conflicting information and don’t always know the true truth.
However, it is my understanding that these “symbols” are very common in use, and do NOT have a “footprint” associated with them. As not having the same software library requirements, these items got separated to make writing the initial source code easier.
The PWR FLAG is also included in this section of code, and AFAIK the only reason for the power flag is for the DRC source code to function without error.
And, I may be wrong on some or all of the above. I’ve seen discussions with different answers and that is my understanding as I applied my own mental filters. If anyone can correct me on any point, I’d appreciate it.
I’m going to have to disagree back. I have to use dozens of different programs in my work and hobbies. I have no desire to have to memorize the different hotkeys for every single one of them. Decades of UI research have definitively shown that users overwhelmingly prefer GUI interfaces as they do not require the cognitive overhead of having to remember various arcane command-line or hotkeys for a program.
Yes, a regular user that is using KiCad all the time will learn and love the hotkeys. But I’m also willing to wager that is not the majority of people who would use KiCad. There are tons of hobbyists that are going to use it for a couple weeks to design a PCB or two and then put it down for 6 months before using it again. They are going to use the GUI. It makes sense to streamline and optimize the GUI for that large user group. It’s not like making improvements to the GUI requires the removal of hotkeys.
A number of resistors and capacitors on a board often are of the same type, using the same footprint and 3D model. A rational thing to do then is to assign footprint and 3D model to the first one of the kind, and then copy that to all the other locations on the schematic. It saves a lot of work.
Such a function would be nice to have (I think) … but I think it really makes sense if it is coupled with a tag on the components in the lib. What I mean is this: When we have the new format, we should enabled marking them as “BASIC” (or something like that, much the way Power-symbols are marked). Then the special button should display a list filtered for these marked symbols. This way, if you build your own lib, you can mark whatever you wish … e.g. your super-standard 0805-100nF-cap … your your belovedPackaged-1N4148-derivative
How about something like a component bin (see the right side)? When you first start designing a schematic you add your most used parts to the “component bin/cart”, then you simply drag&drop them from there. This would also solve the discussion of what should be in the “basic device” list.
I don’t understand the request here. You open the part selector and type the name of what you’re looking for, then hit enter. The “basic devices” in the library have really short, simple names, so that’s a piece of cake. I don’t see how hotkeys even factor into this. Typing a query into a search field isn’t “hotkeys”…
As for it logically following that the “power port” shortcut could be removed too - I would do just that if I had the authority to make that decision… again, you just open the part selector and type the voltage you want. And if you want to browse them, you can just type “power” to filter the browser.
Also there is the history section.
As soon as you put a symbol into your design it is listed there. In most cases this history is filled very fast with what you need in this design.
The current push towards “atomic” parts kinda muddies the water here. Resistors and capacitors would have preassigned values and part numbers. Even copying components becomes a problem.
There is no such push among the core KiCad developers that I am aware of - I think I am the only one of us who is in favor of that, and I have little to no say in the library management aspect (especially considering I deviate so far in that area from the others).
Can you describe a little more about this push to atomic parts? This and other discussions on here have been making me think about how components would really benefit from more of an OOP-style data structure and I think that might be along the lines of something like atomic parts. Is there a good discussion thread to reference?
You would not want to have a capacitor symbol for each type of footprint like in Eagle, and as has been written above there is no push for it. Personally I never use CPCB; I assign everything from general symbol libraries in the schematic editor and then at some stage before I lay out the board I assign footprints to the symbols in my schematic. By atomic parts I would understand that there for instance was a footprint for every single resistor value, with an associated 3D model with realistic color bands or other markings on the part indicating the value. This quickly breaks down as the number of footprints to select from becomes enormous, and yes my strategy would not work for that. However once a symbol has been added to the schematics, I can add or edit the footprint and 3D model assignment to the first kind of the part in the schematic editor without changing the symbol in the library, and then keep copying that part. This also works if there originally was an incorrect footprint assigned to the symbol. There is no need to make a special symbol version in the library for it, although for special parts that can also work.
I agree that if it were a more inherently atomic part model in KiCad, it wouldn’t make much sense to have a basic device button. But given that the schematic portion of KiCad is built to be more generic, it makes sense to be able to just drop in generic parts into the schematic as easily as possible and then fill in details as necessary.
Regarding the atomic/CvPCB argument, I’m sure this ground has been covered very heavily, but I think that it’s a false dichotomy. Really both approaches fail to capture what is actually going on.
Really, there’s several sets of data associated with a part that are all at least somewhat orthogonal to each other:
the symbol - this captures the high-level logic associated with a part - e.g.: all 74HCT245s will be the same in this regard - 8 A<->B level shifters, an enable, a direction and power ports.
the footprint - The physical layout of a part, both in terms of 2D board layout as well as 3D models.
the electrical characteristics - pin capacitance, max/min voltages, signal propagation times, etc. This is a logical place to also store manufacturer info as the electrical characteristics are generally tied to a given manufacturer part number.
The BOM - info about supplier price, availability, what the user has ordered in the past, future order planning, etc.
Really, any atomic part strategy that captures all the useful info has to tie these 4 things together. It’s not just a footprint-symbol linkage with a part number tacked on. Eagle basically does that and I know that trying to capture the intricacies of buying parts from different suppliers, dealing with varying electrical properties on different models, etc was terrible.
If there were a sufficiently well-populated set of default libraries for these 4 datasets, even existing tasks like linking footprints to symbols is going to be taken care of in a lot of cases. E.g.: I pick out a 74HCT245 part for my project. KiCad can then follow the symbol-electrical/manufacturer links to give a list of different 74HCT245s available from different manufacturers with notable differences in electrical properties as well as the available footprints for each. I put some edge conditions on the acceptable electrical characteristics and select an available footprint from the manufacturere parts that match my criteria. That takes care of the footprint association and now I’ve got project-level data that allows constraints on the specific manufacturer part numbers that match what I want. When it comes time to deal with part ordering and management, it’s easy for Kicad to just give me a list of compatible manufacturer part numbers and can search across suppliers to give me price breakdowns and availability all collated in one place for me to look at. I can also use KiCad to keep track of past part purchases to have a complete supply chain management system built right in.
Also, having things like electrical properties brought in as a separate units allow KiCad to add a bunch of very useful functionalities. For example, you could have the individual signal paths from a chip with characterized capacitance and driving power going to another chip with certain rise-time requirements. A built-in SPICE simulator can then easily tell the user if a trace connecting those two pins is too long, generating too much parasitic capacitance to meet the receiver’s rise-time needs. Kicad can then look at alternate version of the chips with different drive power or rise-time requirements where the other electrical characteristics meet the user’s requirements and selected footprint and list out suppliers, availability and pricing.
I realize that this is such a radical reworking of how Kicad would work that it’s never going to be implemented. Even if the devs were willing to retool the program logic to that leve, it would require large numbers of automated data sources from the manufacturers to get all that data and make sure it’s up to date. However, I think that it’s still valuable to rethink the whole problem in terms of each part being decoupled into many datasets, not just a linked footprint and symbol.
This would be a waste of time. The reason some use atomic parts is that they use kicad not only to design the pcb but also for the material management. Atomic parts help there by having the order numbers or some house part number already assigned in special symbol fields.
That’s the drawback behind having every part as an atomic part.
I don’t use atomic parts for resistors and other devices where the value is the only difference. My house part number has the value of the resistor in it. This way i theoretically could use a python script to generate the correct house part number from the fields in my resistor symbol in combination with the value. (Currently i just fill out the hpn by hand for each resistor value i use. But i plan to create such a script as soon as i have a bit more time.)
But for parts like integrated circuits, or even diodes i currently use atomic parts.
I didn’t say it was from the developers, yet your new “component” selector embodies the whole notion of atomic parts.
Well I too have a “professional background” for what that is worth, yet I think that what sets KiCad apart from the rest is it’s genericness.
And here we have yet another.
Anyway, my point was, regardless of whether the “push” comes from developers, librarians or users, that the waters become muddied for anyone who uses atomic parts in their library. A “basic device” button makes no sense nor does the ability to copy components.
I don’t think that is saved between sessions is it? A simple way to implement favourites/MRU might be to save this history in a project specific session file, if not the project file.
Keyboard shortcuts may be eschewed by some, by I find them really handy. The sequence “a” “r” “enter” “enter” places a resistor, a lot quicker than using the GUI with the mouse. “Insert” “enter” places another.
