There aren’t any published minimums. At the beginning, it was just a matter of getting the lead devs flaired. I’ll let the @KiCad_Developers decide who should have flair otherwise though.
Altium is part of the Solidworks PCB package, it has been on the market for about 3 years.
https://www.solidworks.com/product/solidworks-pcb
ahh there we go
so there is the Mentor:NX, Altium:Solidworks, Autocad:Eagle
kicad does something comparable with freecad
Autocad isn’t paired with Eagle.
It’s just Fusion 360 which was paired with Eagle, now they are making it part of Fusion 360 for all those sweet vendor lock-in benefits (for them)
The KiCadStepUp tools are a great bridge between KiCad and FreeCAD.
I think one of the primary differences between open source tools (not just KiCad) and proprietary tools is the proprietary tools are much better integrated.
for better or for worse…
It would be better to have an open format, not just the final exchange (STEP) but for the design (constraints). Too much integration like that results in vendor lock-in meaning they can start holding your data hostage as they know to migrate isn’t worth the cost of increasing the entire suite by an extra 10%
you should be using a tool because it is the best for the job not because you have no other choice… open data exchange means companies need to innovate, fix things, provide value for money rather than just just sit there knowing they have your IP locked in their IP
2 Likes
Good Eagle import is strategically important for KiCad, AFAIK it has been so when Autodesk changed the licencing, and probably it will have a spike again when Autodesk starts pushing the migration (more aggressively). KiCad should be prepared well before that.
IMO the importers should be detached from the release policies, it should be possible to change an importer radically or even add a new one even for bugfix releases. They don’t add or change functionality of KiCad itself and they should follow the external file format requirements when they change. I don’t know if there’s any fixed policy for that at the moment.
It’s possible to write an importer as a python plugin, at least for pcbs. When eeschema gets it’s scripting API we will be all set.
I agree that maybe importers shouldn’t be part of the kicad binary and tied to it’s release cycle but only after all existing importers are extracted as quality first-party supported plugins.
But then why is anything part of kicad and even every button not just a python plugin 
There are reasons for release cycles. The importing is still very very much sensitive to kicad’s internals itself and the python scripts will quickly need to start playing games to handle the version differences in what is supported. (i.e. there are objects in eagle/altium/cadstar we can’t handle currently, there are transforms, etc,etc)
I myself loathe python as an language so I am not going to be converting the eagle converter to python with the fixes I have planned. Maybe someone else will.
1 Like
Well, “current kicad devs working on importers don’t like python all that much” is a reason to not have importers be a plugin but it’s not a good reason.
Importing is sensitive to internals now but when formats are stabilized and python api is untied from swigged cpp objects there will be no good reason to keep importers baked into kicad executables.
Say kicad releases v10 which supports importing altium v30. And 3 weeks later altium releases v31 with updates to it’s file format. Well, tough cookies, wait for next kicad binary release which may be in few months, maybe a year.
If it was a plugin, it can be updated within days.
At least in theory. In practice who knows when there will be a stable full featured python api and who knows how will object primitives evolve in kicad or other packages and if it will be possible to maintain mapping using the stable api. So this is merely a thought exercise at this point.
1 Like
That’s a good question. Why use C++ for things which are not performance critical and would be easier to do with python. There could be the core C++ part and then the UI layer which could be implemented in any technology. That’s where KiCad is slowly heading at, but I don’t hold my breath.
Also remember that it wasn’t me who suggested that the importers should be detached from releases. Only that they would be excepted from the release policies (only bugfixes for x.y.Z releases). I don’t see any problem for example releasing an EasyEDA importer in 5.1.10. It doesn’t change KiCad file format or functions, not even documentation, it just makes possible to conveniently import files which couldn’t be imported before. The result would be compatible with 5.0.0. The only requirement is that the importer doesn’t cause problems and the imported result is meaningful. It’s imperfect anyway.
Two years release cycle is just too long to wait for importers to catch up with external software file format changes. (Well, we all hope that it will be at most one year in the future. If 7.0 takes another two years it may be too late to catch all those migrating Eagle users who have used the then latest Eagle.)
Neither did I suggest that the importers should be (python or other) plugins only.
2 Likes
UI is performance critical (rendering part) so kicad ui will not be reimplemented in any other language any time soon. But really this isn’t about performance as much as it is about massive amount of code that would need to be rewritten. Essentially same reason why kicad won’t switch to QT.
I won’t speak for core devs but my understanding is that only bugfixes for point releases policy is there because there is no manpower to maintain 2 separate divergent codebases. I.e. in your example the EasyEDA importer would essentially have to be implemented, reviewed and tested twice, for 5.1 and for master. So it’s a no go.
1 Like
That’s not true, or literally it is, but you’re still wrong. It’s a fact that an interpreted language interface to a C++ UI library is practically as efficient as the C++ implementation.because the low level stuff is C++ anyway and the interface layer is thin, only simple function calls etc. Of course it depends on where the border of the layers is in the application. Performance critical stuff can be moved to C++.
Only simple function calls add quite an overhead when you make hundreds of thousands of them for rendering. And then there are language quirks like GIL in python to account for, etc. So in theory interpreted languages with c++ internals are just as fast but in practice there are limitations.
But like I said, this isn’t really about performance, it’s about legacy code base.
But you wouldn’t do that in python if the UI layer is thin. For example pyside (the python wrapper for Qt) just wraps the C++ API and if you don’t use the low level stuff but only create and handle the UI it doesn’t add practical overhead. Rendering is done in C++ anyway, and in OpenGL.
Yes. It’s unclear to me what the actual plans or direction for getting rid of the UI (wxWidgets) stuff in the KiCad backend is. IMO a nice plan would be to have maybe three layers, the low level backend, the middle layer between the backend and the UI, and then a thin GUI which would be nothing but the widget stuff etc. without calculations or anything like that. Even the functional structure of the UI would be in the middle level.
If the API of the middle level would be clear and stable it could be pythonised. Then the GUI could be wx, GTK or Qt, C++ or python. Or RPC or whatever.
I don’t know how that would work in practise, though.
not surprised at all, Eagle importers were not written well
Most devs seems to be registrated in this forum and maybe we can think about virtualization of the physical stickers by diffrent colors for lead devs and beginners instead of using snail
[quote="@Seth_h wrote:"
As a token of our thanks, KiCad Services would like to send you a laptop sticker (also adheres to water bottles, hardhats and car bumpers but not dogs or cats) that you can proudly display. The sticker will say something along the lines of “I helped build KiCad Version 6”.
In order to do this, we’ll need to know where you receive mail. If you’d like to receive the sticker, please fill out the form at https:/dev/null
Thank you again for all of your work!
-Seth
[/quote]
After sidetracking it’s interesting to read the old thread Why Choose KiCad over Eagle? again from a historical viewpoint… “With Open Source your own your own data, it won’t be lost” etc. may be clichés but this time it became true.
This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.