KWinFT Projects Hit Beta Ahead Of Stable Releases Aligned With KDE Plasma 5.20

[bug77]

Did you just ignore a legitimate concern to make a stupid, unfunny joke? Qt is very much in power to lock KDE out whenever they want. Might be just a matter of time.

How would Qt do that with the source code readily available and GPL licensed?

[angrypie]

Yeah, sure, that makes perfect sense.
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?

Did you just ignore a legitimate concern to make a stupid, unfunny joke? Qt is very much in power to lock KDE out whenever they want. Might be just a matter of time.

[JackLilhammers]

https://www.copperspice.com/

https://www.copperspice.com/docs/cs_.../timeline.html

I tried to use it because it's interesting, but Qt seems easier and cleaner.
Also CopperSpice has no python bindings

[Mario Junior]

KDE developers BTFO!

[d4ddi0]

Yeah, sure, that makes perfect sense.
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?

https://www.copperspice.com/

https://www.copperspice.com/docs/cs_overview/timeline.html

[JackLilhammers]

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.

Yeah, sure, that makes perfect sense.
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?

[Alexmitter]

tildearrow I’m cheering any de-cute effort.

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.

[carewolf]

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.

Branched out? It is where it started! It is older than C++98, back then there was no reliable standard library, they were different between every platforms, so a cross platform toolkit's job was to offer a consistent alternative. As time goes by more and and more can be let go, though there are still key difference that still make some Qt classes very useful even with standard alternatives. Especially QString is not an std::string replacement and can't be replaced by it, QByteArray is the std::string equivalent. The container classes are mostly just copy-on-write versions of the standard library classes these days, I think in Qt6 QMap just wraps an std::map with CoW semantics and superior Qt syntax.

Besides the standard library is way too primitive for a GUI toolkit. The majority of Qt has no standard library equivalents.

[miabrahams]

Impressed by romang's drive to tackle this. Curious to try it out sometime!

[JackLilhammers]

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 agree that reimplementing libstdc++ is not the best of ideas, but Qt is old and when it came out C++ was way different.
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