Which tools, exactly, are you saying should be part of KiCad and not a plugin?
Is there a feature request already on GitLab asking for this tool to be part of KiCad?
2 Likes
It is too early to ask for features for different electronics at the moment there are not all the main features for consumer… Such as panel boards full-fledged output of production files in different formats, etc… And what is the point of asking all this if there are monsters of the industry in which people work before our eyes)) there are all these moments
I don’t understand your reply at all, so I don’t think this is going anywhere useful.
4 Likes
That would be ideal. But the downside of this is that if the person developing the plugin is a professional, then he would expect to be compensated for his work. Financially. And stable financial compensation in open source world is an unresolved issue. So we get what we get. And if we look at: KiCad itself, some of the plugins and official libraries were all developed/maintained by amateurs/students and such and final result ain’t all that bad.
As with all software development we are bound to The triangle. Given that there is no money involved and we want to have quality there is only on thing that we can trade for quality features and that is time. So we have to be patient. We have to be patient with KiCad devlopers, we have to be with librarians, we have to be patient with plugin writers. And for those who lack patience there is KiCad Services.
Your wish is directly opposed to the main reason why have a plugin API/binding/interface. Just imagine Google officially supporting all of the chrome extensions.
One makes a plugin API/bindings/interface to enable the community to expand your program without any additional/significant drain on your resources.
So when you use plugins (within any program) there is always the danger that plugin will lose support (just think of the number of different web browser extensions)
You are simplifying a bit too much. Nobody said that 90% means mostly Arduino users. I don’t know how well do you follow KiCad development, but not all new features are mainstream (if we define mainstream as Arduino users). Database support is certainly not a priority for most hobby (arduino) users. But we got it. The same goes for Cadstar importer. Complex DRC rules language. Etc…
And even if some features which are requested by wider audience (e.g. 1998) it takes time do develop the required foundation. And if there is a plugin which solves most of the requested feature I imagine that this might relieve the developers to focus on more urgent issues.
3 Likes
А какой ответ вы хотите услышать если люди вынуждены пользоваться сторонними плагинами без гарантии работоспособности по причине отсутствия этих функций в самой программе ? Или вы не знаете как выглядит процесс от идеи до конечного продукта ?
Edit / Translated (Paulvdh):
And what answer do you want to hear if people are forced to use third-party plugins without a performance guarantee due to the lack of these functions in the program itself? Or do you not know what the process looks like from idea to final product?
You did not understand a little what I wanted to say… Plugins are great and they are needed but at the moment all the main functions should be supported by Kicad itself then it will be a full modern cad… For example, in altium, I can make any board with its purpose specifics while not using plugins at all because all the main things there are part of the system and not the python plugins… I am very sorry that those grants that are allocated to developers and donations are not able to affect this at the moment
Ahh, it took a while that your thought came through. Thanks for taking the time.
I can make any board with its purpose specifics while not using plugins at all because all the main things there are part of the system and not the python plugins.
Sadly, this is the current state of KiCad. If it does not suit your need nobody will judge you if you use different solution.
V8 is very unlikely to have any of the features you are looking for if you can’t explicitly name any of those features (and find or create them on GitLab as feature requests)
1 Like
Boy, this thread… Some people are complaining that not enough effort has been made to implement features in core KiCad while others are lamenting that not enough time was spent implementing the plugin system and ensuring continuity. 
Obviously we’d love to have done both.
8 Likes
the discussion started because people complaint that losing a feature already implemented / available is a bad thing.
Trying to reiventing the wheel each main k release cycle is something I cannot find in any proprietary or open source product…
Obviously this is a bad thing, at least imo.
And even more if you don’t develop features internally nor allow a stability for plugins that are giving some missed features (for free), you are losing on both sides imo.
4 Likes
Do you want to hear what turns out to be the editor of gerber files and board panels?) Or a full-fledged yield of fails for production?) Just look at the plugins and it becomes clear what you need))
From the very start of this thread:
Is this the tool that you are saying disappeared? It was removed from the toolbar on the right side because it is rarely used and we wanted to prevent that toolbar from getting too large, but it’s very much still there.
2 Likes
This is not that this is not allowed badly) Imagine that the necessary plugins that did not just provide convenience, namely, replaced some of the missing functions of the kicad stop working and stop further development)))) as a result, all this turns into a dead fork of the githad)))) and you are looking for another cad)
This could be on a closed source environment, not on open source… If something really useful is in lack of development, it always possible to fork the repo and start a new living cycle.
Think i.e. to openoffice and libreoffice… open source is a nice beast 
5 Likes
It happens in the form of python plugins instead of the functions of the kicad itself and I would like to repeat that this is not about any interface improvements or window arrangement, namely the main functions of cad as a tool for electronics)))
Will you allow that what is main function from your perspective might be auxiliary function for somebody else (and vice versa)?
Furthermore, I’ll emphasize patience again. However fast you wish that things would move, they usually move much slower. But now and again some functionality gets folded from plugins into core KiCad (Lenght statst plugin feature is implemented in Net inspector, Teardrops as a plugin are now available as a core tool, …) But it takes time
and for that reason at least it would be wise not to break plugins functionality, having a win/win panorama
2 Likes
Of course, I admit from this we get arduine conditionally… And so that this turns into a more similar tool for boards, plugins make a python, both the necessary replacement functions and not very much in the form of archiver converters, etc.
1 Like
Yeah, that would be nice.
I don’t know what is your experience with python bindings changes, but from my point of view just the python bindings changes were not so bad. For most of my plugins I have some testing suites, so I can spot and fix the issues quite easily. The main issue that I’ve had this year with V6/V7 migration (compared to V5/V6 migration) was getting swamped by all the issue reports. And this is most likely due to three factors:
- V7 was released during the busiest time of year at my job. V6 was released just before new year holidays so I had some free time. Catching every cold that kids brought home didn’t help
- There are more KiCad users which means that there are probably more plugin users, so I got more issue reports immediately when V7 was released and I didn’t update my plugins.
- PCM significantly increases plugin discoverability and ease of installation. Again more plugin users.
But I imagine that you’ve had more issues with python bindings changes as your plugins deal with deeper KiCad datastructures (geometry description, …) so I feel for you.
Finally I have to say that, from my experience KiCad developers also extend the python bindings and try to revert/fix/implement workarounds if they are aware of the issues and (I assume) fix/workaround is possible