I don't think KWin as a compositor has to rely on Qt. It's just wrong design, so I totally support Roman's goal here. Qt should be limited to UI use cases, not used as a replacement for C++ standard libraries which Qt tries to do in quite a number of areas.
Announcement
Collapse
No announcement yet.
KWinFT Projects Hit Beta Ahead Of Stable Releases Aligned With KDE Plasma 5.20
Collapse
X
-
Originally posted by shmerl View PostI don't think KWin as a compositor has to rely on Qt. It's just wrong design, so I totally support Roman's goal here. Qt should be limited to UI use cases, not used as a replacement for C++ standard libraries which Qt tries to do in quite a number of areas.
Using Qt for C++ development is so much easier, than standard C++. You have signal/slots, JSON-, XML-support, HTTP(S) support etc.
Compare also QVector with std::vector. QVector has a contains-method, while for std::vector you have to use std::find() which produces unreadable code.
- Likes 1
Comment
-
Originally posted by Steffo View Post
Qt is not just an UI toolkit....
Either way, for high level language I'd go with Rust over C++ if there is a choice and I'd go for libstdc++ over Qt analogs otherwise.Last edited by shmerl; 27 September 2020, 03:44 PM.
- Likes 1
Comment
-
Originally posted by aufkrawall View PostWhat is the status on merging/replacing upstream?
With any luck, some distros will pick it up once it goes stable. I see Manjaro already does that and there's an AUR for Arch as well. I'm going to give it a try once I get 5.20.
Comment
-
Originally posted by shmerl View Post
I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.
Either way, for high level language I'd go with Rust over C++ if there is a choice and I'd go for libstdc++ over Qt analogs otherwise.
I mean, Qt is older than boost and just 1 year younger than STL.
Qt 6 will be based on C++17, so hopefully much stuff will use more modern C++.
I don't know KWin's code, so I can't say if it would be better off in pure C++. I think it really depends on the specific case
Comment
-
Originally posted by shmerl View Post
I think it branched out in too many places. And when it's trying to reinvent the wheel from libstdc++ - that's not good. And I'm not convinced that it's actually better. It's using rather ancient approach to code design. Modern C++ is far ahead already.
Besides the standard library is way too primitive for a GUI toolkit. The majority of Qt has no standard library equivalents.
- Likes 1
Comment
-
Originally posted by 144Hz View Posttildearrow I’m cheering any de-cute effort.
But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.
It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.
- Likes 1
Comment
-
Originally posted by Alexmitter View Post
De-cute-ing should be the main focus for KDE in their next version. The more they depend on Qt, the easier is it for the greedy Qt company to pressurize them into making changes to this already very weak contract that are purely in the favour of the Qt company.
But the actual sad story is that the GPL failed to protect freedom here. It relies too heavy on the idea that a re-licensing is nearly impossible if multiple people own the code in one project. But as the Qt company only accepts contributions if the owner gives full rights to the Qt company, and the KDE people being fully happy with that creates the situation where the Qt company is not just able to re-license community contributed code under their greedy proprietary license but also be in the position that it can stop releasing GPL versions. KDE e.v. could then re-license what was GPL to whatever they like but would be cut off from all the progress made after that.
It was a bad idea to stick with Qt after the 4 years of them refusing to even consider the GPL. Back then would have been the best chance to switch to a FLOSS and better tool kit what would be harder but is still 100% necessary today.
But why stopping at Kde? There are many other projects that need True Freedom™!
Let's rewrite everything written in Qt with a better and truly free toolkit!
Do you have any suggestions?
- Likes 1
Comment
Comment