I’ve been trying to get used to KiCad and have been spending a lot of time in the part library editor simply because I either can’t find the part I want or I’ve found it but there something wrong with it.
Anyways, I find it puzzling that there’s two buttons related to saving a component. From the 4.0.6 docs…
http://docs.kicad.org/4.0.6/en/images/icons/save_part_in_mem.png
Save the current component changes in memory. The library file is not changed.
and
http://docs.kicad.org/4.0.6/en/images/icons/save_library.png
Save the currently selected library. The button will be disabled if no library is currently selected or no changes to the currently selected library have been made.
I had been hitting the first one and saving only to memory because it pops out more and, like everyone else, I only resort to docs unless I hit a brick wall. I now can really “save” a component but here’s my questions:
-
What does it mean to “save the current component changes” to memory? If I just edited it, isn’t it already “in memory”? What memory are they talking about?
-
When would I EVER merely save to memory and not to file? If I edit a component, I really mean to edit the component. Files have backups, we have git, etc, its not a big deal to change a file. Why are there 2 buttons, isn’t “save to file” enough?
The Andy_P message is correct and well explained.
But I think the main problem is a lack in a clear path on how to manage and store components.
I hope that in a future will be taken corrections.
My proposal will be the following:
-
Official Kicad library are reachable via git or a local copy in local. All official update are automatic between library maintainers and git or local copy.
-
Local personal libraries are stored into a user folder. All components edited by user or new components created by the user are stored here too.
-
Every time an user add a component into schematic the search needs to be done first into a local personal libraries, otherwise not present it is searched into the official kicad libraries. The added schematic component needs to be added to personal library too.
-
Component needs to link also the information concerning the footprint
-
The user when sure about modifications can submit them to the libraries maintainers team.
I think this approach can help increasing number of available components and give a clear sequence of actions.
Nevertheless this approach can be increased and better. Hoping that developers can take in consideration such kind of considerations.
Antonio
1 Like
Thanks Andy, for taking the time to carefully explain the use case!
Yes, I think that Git had the same kind of problem for a long time. Git doesn’t enforce any kind of workflow, you can accomplish the same thing in many different ways. As a result, there was a lot of confusion and bad advice going around since the people giving advice and receiving advice weren’t necessarily aware that they may have completely incompatible workflows in mind.
IMHO, it was only when Github introduced the aptly named “Github Workflow” did the masses (myself included) start to really understand and master Git-based version control. There’s not much to it-- its just a prescribed pattern of working that has been thought-through and explained from beginning to end. It makes some opinionated choices that not everyone may agree with but its perfectly workable. And more importantly once someone has mastered “Github Workflow” they’re in a much better position to learn and evaluate nuanced deviations from that workflow.
I suspect that KiCAD might benefit from an approach like that. In other words, no deep changes to the application/UI, just a written, opinionated prescription of “one good way” to take a project from schematic to components to pcb to manufacturing. Like any other complex application, in the EDA space users find themselves in a world of pain if they go against the grain of what the developers had in mind.
