Whatever the reasons for s-expression now being used, I can say with some confidence that KiCad will never change to another format. I leave open the possibility that following a catastrophe that wipes out human life, a future species of intelligent bees will resurrect KiCad and convert it to BML, or something.
I think that is plausible, because the first railway carriages were literally horse drawn carriages mounted on railway wheels, so the gauge might end up being about the width of two horses. Ref : https://railroad.lindahall.org/essays/rail-cars.html
But equally the standard gauge could just be a compromise between the various gauges, of which there were dozens.
There are more acute problems with chosen technologies, or at least one, namely wxWidgets UI library. It was probably good choice back then. Now itâs a heavy burden. affecting almost everything in KiCad.
What would you choose now if you had cart blanche to design KiCad from scratch? I thought for all itâs shortcomings wxWidgets is still the only framework supporting win/mac/linux and having decent python bindings.
Oh, I just checked qt python is now on windows so I guess it is an option?
Python is a first class citizen nowadays in Qt. Not perfect yet, but it will be better. It was in hiatus for many years (although there were 3rd party bindings). https://wiki.qt.io/Qt_for_Python
For now Qt is the dominant multi-platform GUI framework.
This could potentially (not that likely though) change overnight if the licensing went hostile, as has happened with Oracle Java
QT seems to have more Linux developer weight behind it because it forms the core of the KDE desktop applications usually. They also have a company with more employees working on it (wxwidgets does have a developer in a consulting company, but I think everyone else has other jobs).
The funnier thing is that there is work now to actually make a wxwidgets backend that uses QT. So you can get the wxwidgets API with the QT library backend.
It canât happen with Qt, it has been secured by some contracts. Otherwise it would have been too risky for the KDE project to use Qt (KDE libraries are built on top of Qt).
I also remember another post telling that if someone wants to port the thousands of lines of Kicad to QT he (JP) is not opposed but it will last years untill the current state of Kicad is reached.
I understand the reasoning of JP (and Wayne), but only partially. One can never prove that Qt wouldnât have less problems unless KiCad would be implemented with Qt. So thatâs catch 22 (or something like that). But one can be pretty sure that Qt would have less problems.
The realistic way to go is to separate the backend completely and make it standalone (library), then start implementing the UI from scratch while the old one is still developed.
I once converted a non-trivial application from old KDE/Qt3 to plain Qt4. Not completely painless, of course, but I just donât believe it would be worse than fighting with wxWidgets. (This is a comment to JPâs opinion that âI remember coworkers who spent a lot of time to convert their work from QT3 to QT4 âŚAnd QT4 is not the latest version. This is an issue we never have with wxWidgets.â)
I suppose a âPC beeâ is a natural technological evolution of a âquilting beeâ? Something like a hands-on, in-person event sponsored by a Makerspace, where people go to show off and talk about their latest project, and socialize over coffee or other refreshments. A little bit like KiCon, but with a catchier name. What a quintessentially geeky, nerdy, social gathering! I can imagine bringing my wife along . . . . and getting divorce papers the next day.
Or perhaps re-name this Forum as the âPC Beeâ. Sort of the same idea, but implemented with a different technology.
Every industry has their standards. In the FPGA world almost every vendor uses TCL for scripting and configuration. Lisp variants or S-expressions are used because they are: easy to parse (some compilers precompile high level languages like C/C++ etc into s-expressions before further processing), also an S-expression interpreter can often be written in only a few lines of code and arguably it is easier to read and format. EDA tools have seemed to standardize on LISP variants.
I think there is a conscious effort going forward to try to avoid using wxWidgets specific code as much as we can (and this is being helped by the fact we have the newer C++ standards with their containers and strrings). The tool framework that is in Pcbnew currently (and being expanded everywhere in v6) does a pretty good job of abstracting these things away from the programs and puts all the user input in one place. The main issue then becomes converting all the dialogs and UI elements.
Every UI library has its quirks, but the thing QT has that wxWidgets doesnât is more developer time being invested in it. Iâve been following the wxWidgets mailing list for a while and upstreaming some fixes occasionally, and there are usually only 5-6 people who regularly contribute. The other issue is their release schedule has been somewhat non-existent. There has been this mystical version 3.2 planned for over 6 years, but the problem has been the releases leading up to this have been billed as âdevelopmentâ so Linux distributions have been reluctant to include them (meaning we are stuck on a version that doesnât see very many updates). One thing that QT would have going for it is a better release process/schedule.
âMoreâ developers or development time feels like understatement. According to their own words they employ ~300 persons. There are ~1 000 000 users (application developers).
The other side is that the whole Qt is a huge ugly monster, for KiCad only a small part of it would be relevant, and the C++ desktop widget library isnât so actively developed any more. On the other hand the library is stable and there just isnât much reason to innovate new C++ library widgets after tens of years of proven designs. Most of the new development and innovation goes to QML (including mobile development), 3D user interfaces etc.
If the development with Qt would be started now, Qt version 6 would be the target. See https://www.qt.io/blog/2019/08/07/technical-vision-qt-6. Version 5 is about 7 years old. So, the next conversion would happen within 5 or 10 years. Knowing that compatibility is important to Qt folks and they care about it when making decisions, that wouldnât be too bad. Certainly not worse than being stuck with wxWidgets which probably will not evolve very much.
It would be tempting to write a new UI with python bindings (PySide2). Development is so much easier when you donât have to compile after each minor change to UI code. In a best case scenario you would have the backend binaries installed from a platform dependent package and you could code the UI application without compiling.
A user interface should be (if possible at all) an entirely seprate layer from a given GUI-based application. Anything else might/does work but is in general a maintenance nightmare.
Then again. The main part with KiCad is its GAL, a rather intense interaction layer between GUI and background, which in turn makes the foreground/background layer split approach somewhat cumbersome.