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.
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.
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.
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.
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.
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
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.
