Two More Projects Join KWinFT Fork Of KDE KWin, Beta Milestone Reached

[JackLilhammers]

I have recently been favoring using C++17 instead of going the Qt way more and more, so i kinda get where this team is coming from.

In my opinion Qt5+ focused way too much on JS and let the C++ part go outdated to the point it can be quite bothersome, i get it, closed source businesses probably favor dumb JS GUI design instead of proper performing code since JS devs are way cheaper and easier to replace but for everyone else is a bummer.

I hope they fix their ways for Qt6 but not holding my breath either

I wouldn't call declarative interfaces "dumb JS GUI desing". Quite the opposite.
I'd say that when we find it hard to adapt to change, we blame the tech.
Still C++ in Qt needs more love

[Space Heater]

This doesn't seem to be a good sign for KDE's overall health.

[tildearrow]

Fork Wars, sad cringe. But any initiative to reduce CLA usage is good.

3 accounts he made... I mean 5... No I mean 8!

Ugh I thought you already left us in peace :l

[cmakeshift]

I have recently been favoring using C++17 instead of going the Qt way more and more, so i kinda get where this team is coming from.

In my opinion Qt5+ focused way too much on JS and let the C++ part go outdated to the point it can be quite bothersome, i get it, closed source businesses probably favor dumb JS GUI design instead of proper performing code since JS devs are way cheaper and easier to replace but for everyone else is a bummer.

I hope they fix their ways for Qt6 but not holding my breath either

I disagree. I love QML, and it is very important and useful. But when you are doing complex stuff and have to glue it with performance-oriented native code, the cracks start showing.

At least they recognize the problem of cumbersome interoperability between the QML internals and the C++ side, and AFAIK it is on the Qt6 roadmap to alleviate this. The C++ side is so stable and well-established, that I very much doubt it will change in significant ways besides moving more functionality to make better use of C++17 and 20.

My take on the quality issues with QtWayland is that it is only a priority on embedded usecases (IVi, etc), not the desktop. Sounds like it would be hard to evolve it significantly without worrying/upsetting the OEMs that depend on it being very stable. Something like that could only be remedied with enough interest from the Qt Company, and ideally during an ABI break (Qt 6). But these conflicting interests seem very hard to conciliate as soon as OEMs depend on the codebase, so it might be a good idea for a Desktop Window Manager™ to roll with its own implementation of the Wayland stuff.

[miabrahams]

This doesn't seem to be a good sign for KDE's overall health.

I wouldn't say that. It's good to have innovation from committed and active developers - sometimes you have to break things a bit to experiment, and explore avenues that may or may not work out.

I also don't think the KDE maintenance side seems particularly broken or hostile. My very surface-level peek at what's going on, it seems like forking these libraries makes a lot of sense, since the alternative is to push significant architecture changes into KDE that don't offer much of an advantage for the existing KWin stack.

So to me this seems like an unsurprising development and not particularly worrisome.

[timofonic]

Please merge them into mainstream, please remove the cruft of KDE.
KDE needs to be more responsive, faster and a lot more Wayland friendly.

Gnome needs a lot more serious competition.

[cynical]

i get it, closed source businesses probably favor dumb JS GUI design instead of proper performing code since JS devs are way cheaper and easier to replace but for everyone else is a bummer.

Describing a GUI layout isn’t exactly an expensive task. It makes more sense to use an expressive language for that.

[curfew]

The Wrapland library is now making better use of C++ in its low-level code rather than Qt in those low-level areas, improved encapsulation of external libwayland types, and other engineering improvements.

It makes zero sense to say "better use of C++ instead of Qt". The code is still pure C++ but just based on the Qt framework instead of another library. In the original blog post the author was saying that they're replacing Qt-based C++ code in order to make use of a plethora of native C++ features that are very hard or impossible with Qt's legacy semantics.

[theriddick]

From my understanding this will not help NVIDIA users and Wayland atm is exclusively a AMD and Intel supporting thing. Is that correct?
I have tried Wayland on my NVIDIA card but the control panel didn't work and the desktop was sort of messed a bit.

[smitty3268]

From my understanding this will not help NVIDIA users and Wayland atm is exclusively a AMD and Intel supporting thing. Is that correct?
I have tried Wayland on my NVIDIA card but the control panel didn't work and the desktop was sort of messed a bit.

NVidia is the only one that can support their cards, since they are closed source.