From their manifesto:
> Long ago there was an OpenSource library called Qt. When it was C++ and Widgets, it was great. Then the library lost its way and became focused on phones. It also became dramatically less "open" and much more "you have to buy a license." The C++ Widgets side of the library withered as resources were poured into a non-typesafe worthless thing called QML. This was well after making a play for the medical device market. You can't use non-typesafe junk when lives are on the line.
Their writing style is a serious turn-off.
If being non-typesafe is a turn-off they should not be using C++. They should be using Go, Rust, or some other memory-safe language with better type safety.
The latest crazy Windows IP stack RCE pushed me wholly over into the "nothing new should be written in C/C++" camp. It's clear that secure reliable software can't be done in these languages, at least at scale.
The macho counter-argument of "but I can do it!" doesn't work. Maybe you can. It doesn't matter. Code will be worked on by more people than just you if it lives for a long time. Code "rots" and acquires bugs, and having the compiler catch the worst ones (memory errors, type errors) is a huge win.
If only there was an existing gui library as mature at Qt4 written in these languages, so they could fork it.
As a medical device founder, I personally wouldn't start any new projects in C++, unless I had realtime requirements. Embedded computers are performant enough today that you can easily write app code in safe languages with great tooling, and wont have to worry about complying with increasingly stringent V&V and memory safety standards from the FDA. And if I had to write c++, I'd use libraries and toolchains that were actually verified and had really great FDA quality documentation, which this project does not.
Could you give examples of your preferred stack of language and li raries?
.NET is pretty popular! We use a combination of Kotlin, Python, and Rust. Because of the V&V burden of extra libraries, we tend to only use standard libraries
Thats a lot of red flags to put on your landing page.
Modern C++ standards are the bare minimum you should enforce in terms of software safety and correctness.
I would have expected to see some examples of how the GUIs look. Clicked around for a bit and didn't see one single example. This doesn't look serious at all.
It's mainly a Qt preservation project (The fully open-source parts of Qt, but without the MOC compiler / QML / Qt Declarative) - so not that much different from it.
So, just like Copperspice?
"Modern C++" is the same rewrite costs as if you Rewrote It In Rust, except that at the end you still have C++ and are still on the same treadmill and will be doing this again next time. It makes sense for C++ trainers to promote this, it's repeat business.
Every three years there will be another iteration of "Modern C++" (it seems like some want to now call C++ 20 and C++ 23 "Contemporary C++" instead of "Modern C++" but it's the same again) and you're back to do more rewrites.
This couldn't be farther from the truth.
Not only will a Rust rewrite take 5-20x longer, you'll also be supporting 2 versions (C++ and Rust) for a long time, while doing the rewrite and migration, and that will eat up a lot of dev hours.
I've done incremental C++ migrations and they are not nearly as complex or stressful, especially when you leverage libtooling or Python bindings to write AST-rewriting scripts for those large refactorings.
> Modern C++" is the same rewrite costs as if you Rewrote It In Rust
Certainly not! The update can be done incrementally as pre-modern C++ is (almost) fully compatible with modern C++.
And in some year there will be "Modern Rust"
That’s a weird take. I would expect it not being the same cost to do a rewrite in Rust, like, not at all.
You can do it incrementally with C++, not to mention not needing to hire a team of rust developers. I don’t think you want to let a team of C++ devs that are just learning Rust do a full rewrite as their first big project experience.
Also, when switching from, say, C++20 to C++23, thinking it’s the same amount of work as a full rewrite in Rust is laughable.
Somebody has a bee in their bonnet about a decision in C++ 20 and so we get a project to "fork" some apparently important C++ library so as to fix everything they don't like about it. It's years of rants about how the modern kids just don't understand, condensed into this one fork proposal, so I guess that's efficient at least.
I've heard about CopperSpice before, but I've never personally seen any project use it. Still, it seems they have some passionate developers behind it and actual users. Forking it just because you don't like some newer compiler standard seems a rather bad reason. Do the LsCs developer(s) have the same passion and resources to keep their fork up to date? How are their getting users? Are they going to stick with C++17 forever while the rest of the world moves on? While forks sometimes are a good thing, I'd first try to help the original developers to achieve "creat[ing] something prepackaged and widely usable".
The author states that it's because old UNIVAC mainframes are still being used in the medical world and they don't have 2's complement, which makes it incompatible with C++20. But the machines were discontinued a long time ago with the company finally moving to Intel Xeon CPUs in 2015 [0] - and I'm not even sure if people actually run GUIs with these legacy mainframes (plus the author's stating this will primarily support Linux, but are these mainframes even capable of running it?)
[0] https://www.theregister.com/2015/05/26/unisys_finally_weans_...
> and I'm not even sure if people actually run GUIs with these legacy mainframes (plus the author's stating this will primarily support Linux, but are these mainframes even capable of running it?)
The next parapgraph sounded like they're concerned about bugs from not having the same integer representation as those systems:
> Passing 2's complement data to backend systems or front end sensors expecting 1's complement causes catastrophes.
I don't really understand their concern though--surely all actual C++ implementations that build QT apps and the platforms that run them are using twos complement anyway? Like, the C++ standard change is not making anyone change their integer representation, it's just telling the not-twos-complement people that they're on their own, right?
Of course I'm not surprised not to be following the logic since I have to count myself among "those who never went to college for Computer Science".
Unisys mainframes (not UNIVAC).
Good luck!
I developed a successful medical device on Qt 4.8 and can attest that it was a joy to work with.
Not sure about how the FDA would feel about an old framework. I don't think they would care too much or it would become anymore easy to provide software verification.
So that's a fork of a ~10 years old fork of Qt. Copperspice originally forked, in part, because Qt was not close enough to the C++ standards, and now this (outdated) GUI library is being forked because they make use of a 4 years old C++ standard. Someone should fork LsCs to add support for mobile or new C++ standard. Looking forward to see this happen in 10 years (/s)
In 10 years they will be rewriting React 15.0 from scratch because...