I just wanted to get an overview about the whole 5.0.1, 5.1 and 6.0 version and some stuff in them I do not understand (because of me lacking knowledge in GUI programming).
Afaik the goal of 5.1 is to solve the following problems (and adds no additional features):
change wxPython to a version with python3 support, because python2 will be depreciated
“GALification”, so changing something in the GAL?
Because wxpython relies on an older version than is supplied by current Linux distributions, KiCad is not complied using KICAD_SCRIPTING_WXPYTHON which is needed to run action plugins, although the KICAD_SCRIPTING_ACTION_MENU s activated?
Looking at the build settings:
USE_WX_GRAPHICS_CONTEXT=OFF // off because of wxphyton problem
USE_WX_OVERLAY=OFF // off because of wxphyton problem
KICAD_SCRIPTING=ON // pyhton console?
KICAD_SCRIPTING_MODULES=ON
KICAD_SCRIPTING_WXPYTHON=OFF
KICAD_SCRIPTING_ACTION_MENU=ON // I can only use plugins that do not require wxphyton?
I do not really understand what both libraries do.
How do GAL (graphical abstraction layer), wxpython, cairo and opengl come together?
I think Cairo sends the commands via OpenGL to the graphicscard.
And what are the legacy implementations? Will they get removed altogehter?
Is wxpython only used for the windows and menus?
Why is GTK or QT not used? Or am I completely mixing up different stuff and talking bogus?
And last but not least version 6.
The roadmap I found is really out of date and I cannot find a document which shows what goals and changes the developer have in mind.
Stuff I read about:
better DRC (more rules? more concrete rules for clearance between different classes?)
differential pairs class, so no need for name ending with _N_P ±
…
Will there be the format change of the files? Why do they need them (because of additional stuff like arch-traces?)
Thanks for the help guys.
It would really be helpful to get an overview about the development.
Disclaimer: Not a dev just somebody who follows the mailing list. So some details might not be completely correct.
This means that eeschema will use open gl (or cairo) to render its drawing canvas. This is the same thing that happend to pcb_new when version 4 got introduced. But as the renderer will not reduce the feature set, there will not be a need to keep the old renderer alive for eeschema.
Python 3 support is not the primary goal. The problem is with a library called GTK and wxGTK. This libraries are responsible for rendering everything that is not rendered by open gl / cairo (so everything outside the drawing area) More precisely the problem is with a python library that connects to wxGTK. (This library is called wxpython) This library needs to be compiled against GTK2.x for KiCad. But most modern linux distributions dropped support for GTK2 quite some time ago.
So they use the library that is compiled against GTK3. Sadly the lib that is compiled against GTK3 also changes some interfaces. This means it is not compatible with KiCad. (I do not fully understand the full details of it. For that you would need to talk to the devs.)
Scripting will still work. As long as it does not need anything from wxpython. Sadly the footprint wizards and KiCads python console need this lib so they are deactivated if WXPYTHON is off. Scripts that include wxpyhton for any reason will also not work when this flag is off.
Yes. Definitely to the schematic and symbol file format. Possibly small additions to the footprint and pcb file format.
The schematic file format is quite outdated. The plan is to transfer it over to s-expression. this is the same underlying format that is now used for the pcb side of things.
The reason is that the devs want to add much more functionality to the symbol and schematic.
Right now the alias functionality of symbols is very limited. The plan is to have something called inheritance in the symbol file format. This would allow much more flexibility when dealing with symbols that can share parts of each other. (However the full inheritance support might be postponed for version 7. Version 6 might just re implement the same functionalities as already exist in version 5.)
Another planned addition is pin aliases. So you can more precisely model multi function pins of say a micro processor. (Again this might not be included in the first round of transferring over to the new file format)
And a more powerful “bus” support has also been proposed. One part of it would make hierarchical sheets a lot more powerful. (You could then for example have a hierarchical pin that represents a full SPI bus that includes MISO, MOSI, CLK and CS. Allowing much more abstraction.) There is also talk of having intelligent bus entry points (so you already get labels suggested that fit the current bus)
There are a lot more things planned. The stuff i listed is only the stuff where i remember somebody mentioning that this would benefit from the new file format. (I am sure there are even more things that will benefit from it.)
Rene already explained most of relevant things. Additionally 5.1 will have (the nightly builds already have) some UI changes of which some of the most visible are configuration and setup dialogs.
About the GUI toolkit used - wxWidgets is the choice from prehistoric age when there wasn’t a good free cross-platform competitor available. In my opinion it’s a heavy baggage now, there’s nothing but cons (maybe except for pretty good documentation). But changing to GTK or Qt would be huge and very difficult undertaking and would bind developer time from actual features. At some point it may be inevitable and will be even more painful because there will be more and more details to port, but I don’t see the developers accepting changing the toolkit as long as wxWidgets is actively developed and supported. I don’t know how deeply wxWidgets is integrated, but it certainly goes deeper than just windows and menus. If they ever decide to port to something else I would recommend Qt, and if I’m still an active KiCad user when it happens I might be able to help.
The kicad-developers mailing list is what you should be reading if you want to know more. For now it will be quiet for some time, until 5.1 has been released, because Wayne doesn’t want to distract the developers from making 5.1 ready. But after that I believe the list will explode, so be sure to keep reading it when it happens. Probably the roadmaps will get more treatment then, too. I also believe that many developers have been coding “secretly” and will integrate their works soon after 5.1. Just watch the video which is in the kicad.org main page.
The new footprint editor is another major change. It now looks the same as the symbol editor with the tree view sidebar instead of the active library stuff.
The move exactly tool also got updated.
(This is what i noticed by using nightly for working on some footprints)
I thought so at the beginning when implementing Python 3 support, but the footprint wizard actually does not rely on WXPython which means the wizard still works as long as scripting is enabled. It’s just a bit hidden (“File” -> “Create Footprint” or by using the footprint symbol with the star).
What is not working is the scripting console because it relies on some wxpython stuff to integrate better.
mac testing of python3 is still missing, and the wxpython port to the new toolkit requires testing as well (There seems to be a regression on windows) but I hope to get it into 5.1 but deactivated by default (distros which need it can activate it which is better than shipping without it)
What’s also important, but I haven’t seen activity on it yet is getting gtk3 working in a nice way. With wx 3.1 many bugs vanished and it would be nice to have the devs addressing the remaining ones. Problematic is that a stable wx release with all those fixes is required to have those benefits in the distro builds. wx 3.1.2 was planned for June and is still not published. v3.2 would be a stable release and is planned for the end of year, but I suspect they will manage it.
The GUI toolkit (windows, buttons, menus) are made using wxWidgets.
The main frame of the windows, where the canvas (for pcbnew and now also eeschema) had many different types to get rendered and is now unified under a combination of openGL and Cairo.
A quick search in the mailinglist (which is produces a saner results, because I know better what to search for thanks to you) shows that the discussion of switching to Qt comes up periodically.
It seems even if the resources were there, that a switch to Qt is wanted.
That’s unfortunate I guess (without having deeper knowledge into the topic).
In my uneducated thinking using a well supported, documented and actively developed toolkit like Qt is beneficial, because it scales well with complexity and is really fantastically designed.
In the past I played around GUI programming with Tcl/Tk (legacy sw), which is imho only useful for smaller application. Reading into wx I guess I would classify it in the same reagon.
Anyway, thanks a lot!
That cleared up a lot of things
About kicad+qt: there was the idea of having a kicad-core library which would allow other peoples to only build their own gui, and let the compilcated stuff be handled by KiCad.
Despite the problems with wx, I really like that it allows KiCad to look native on every system. And it seems to get way better at the moment. I’m actually building KiCad with v3.1.1 (dev-version) which fixes many bugs, especially on gtk3. And they also work on things like touch, high-dpi support,… which is important for modern programs.
So does Qt. It has styles which make it look native. It also has native feel in many places. And the “feel” part of “native look’n’feel” can’t be completely true with cross-platform applications anyways.
The main driver behind the UI changes was consistency (both between various parts of Kicad and between Kicad and various platform standards) and simplification.
This led to some things that look a lot like features, including the aforementioned footprint editor changes (for consistency with the symbol editor), an editable pin table (for consistency with global fields editor), direct editing of symbol fields and footprint text items, DRC and zone-fill handling of copper graphics (for forbidden layer consistency), and simplified global editors for Text & Graphics and Tracks & Vias.
here the JP’s point of view on Qt as in my previous link:
Q: Hi all. Maybe in future need to port kicad in other modern gui as qt( https://en.wikipedia.org/wiki/Qt_(software) )
R[JP]: A bit overkilled for this issue (if this is an issue). I am not especially thrilled by QT. This is a very good tool, but it has its own issues. Good luck to volunteers who will port 400 000 lines of code relative to GUI. (80% of code of any application; Kicad has more than 500 000 lines of code)
IIUC big part of the issues with gtk3 are directly related to legacy canvas. There is a huge effort right now to both port all legacy canvas only features in pcbnew to GAL and to make eeschema work on GAL making legacy canvas obsolete. So there is definitely work performed (possibly incidentally) to fix gtk3 problems.
To add to Rene’s point about wxpython. The problem is that most new distribution package maintainers provide both wxwidgets built with gtk2 and gtk3 and apps can use either one (at least until gtk2 is completely phased out) but they only provide wxpython built for gtk3. When app using wxwidgets gtk2 tries to load wxpython it loads wxwidgets gtk3 libraries as well which don’t work together and result is SIGSEGV: https://bugs.launchpad.net/kicad/+bug/1762432
