KWinFT Going Through Code Refactoring, Working On WLROOTS-Based Usage

[mdedetrich]

The reality Steffo is use after free or memory leak bugs are just as likely with C++ as C. Ok some of the C++ ones instead of being a normal memory leak is a object leak but the result is still the same of memory not being freed when it should have been and the data end up exposed when it should not have been.

This is false, if you modern C++ features then you will have less use after free errors compared to C. Of course you can't completely eliminate such errors, but the occurrence is going to be a lot less frequent. Saying otherwise is misleading.

[AHOY]

Does anyone know why he choosed wlroots over Mir? The latter is based on modern C++.

wlroots (WLROOTS for non screaming individuals) is the most used and mature library with real world desktop usage by a long shot.

Mir being from Canonical is another deal breaker for many developers. Not to mention they had their shot at EEE'ing Wayland and lost.

[Steffo]

There is more than 1 standard that is modern C++. Mir does not have a large number of users so they could decide to take different requirement to mesa3d and qt libraries.

C++ is backward compatible and if KWinFT uses C++ 20 and Mir C++ 17, there should be no problem. A library author usually knows about compatibility issues and is cautious regarding raising the requirements.

Sorry C++ provides no real protection again use after free or memory leak bugs.

It doesn't provide 100% protection, but it makes it less probable than with C.
You just ignore concepts like RAI and smartpointers which are far superior than goto.

[ResponseWriter]

Might be time to give this another try. Last time it introduced some issues that weren't present on kwin but all I need at this point is for it to be more stable.

I've actually switched to Wayland this week with 5.22 release and it's only once killed all my Xwayland windows requiring a new session to get going again (after restarting sddm & dbus). And the lockscreen broke after the display was off for a few hours but I can probably get by without it for now.

[oiaohm]

Well KWinFT also uses modern C++. I think a library like Mir would update their C++ standard requirement carefully.

There is more than 1 standard that is modern C++. Mir does not have a large number of users so they could decide to take different requirement to mesa3d and qt libraries.

This is actually a good reason. But I really don't like C, because it is more probable that use after free or memory leaks bugs occur.

Sorry C++ provides no real protection again use after free or memory leak bugs.

https://www.zerotier.com/2017/05/05/the-horror-in-the-standard-library/

Steffo quite a few cases where the standard C++ library has in fact been the cause of memory leak bugs and use after free events.

The reality Steffo is use after free or memory leak bugs are just as likely with C++ as C. Ok some of the C++ ones instead of being a normal memory leak is a object leak but the result is still the same of memory not being freed when it should have been and the data end up exposed when it should not have been.

This would be a different matter if we were talking about go or rust or something else design to be a safer language. C++ was not designed to be a safer language only a faster language to perform development in. C++ is just a faster way to write bad code than C. There is a lot of false belief that C++ gives a code base quality improvement.

[mdedetrich]

Really happy with KWinFT, been using it for a while (its also ultra easy to setup on Arch/Manjaro) and have had much less issues compared to the original KWin. I just hope at some point once the dust is cleared with all of the ironing out of wayland problems that it eventually gets upstreamed and replace normal KWin.

I understand the circumstances as to why the fork was created in the first place but there are obvious issues with how sustainable this approach is. I think that ultimately KWinFT will have to prove just how much better it is than normal KWin to have a hope of replacing it.

Kwinft is developed for KDE so obviously it will maintain compatibility with KDE forever. The problem here will be can the sole developer of Kwinft keep up with the upstream in terms of features. Based on his description of changes to Kwin core, merging new features from upstream must not be feasible at all. And of course he'll in turn be at the whim of the KDE maintainers with whatever features they want to introduce.

Well regarding the point about being at whim of any feature from KDE upstream, I don't think this is a problem in reality. KWin (and its dependencies) have one goal, which is a window manager for KDE. This means that by definition, any new feature that does get introduced is going to be a feature that a window manager needs to handle for desktop use anyways.

[curfew]

yes, it is correct... for now... as i was addressing concerns that this cannot be hold true in the future (because of further separation in developments)

Kwinft is developed for KDE so obviously it will maintain compatibility with KDE forever. The problem here will be can the sole developer of Kwinft keep up with the upstream in terms of features. Based on his description of changes to Kwin core, merging new features from upstream must not be feasible at all. And of course he'll in turn be at the whim of the KDE maintainers with whatever features they want to introduce.

[Steffo]

Modern C++ would be enough reasons not to use it. wlroots being C does turn out to make things simpler.

Well KWinFT also uses modern C++. I think a library like Mir would update their C++ standard requirement carefully.

Other thing at this stage as well more parties use wlroots than Mir as well so more parties to share maintenance with.

This is actually a good reason. But I really don't like C, because it is more probable that use after free or memory leaks bugs occur.

[oiaohm]

Does anyone know why he choosed wlroots over Mir? The latter is based on modern C++.

Modern C++ would be enough reasons not to use it. wlroots being C does turn out to make things simpler.

Think about this if KDE code and Mir code update there C++ standard support out of alignment with each other the result can be incompatibilities in interpretations. C might be horrible and old but horrible good feature about is it standard changes slowly leading to low alignment issues. There are enough C++ incompatible issues that can come up from mesa3d libraries leading to valve supporting libcapsule work in the first place. Yes you already have a two way tango between mesa3d and kwinft over C++ features that can lead to code reworks without making this a three way.

Other thing at this stage as well more parties use wlroots than Mir as well so more parties to share maintenance with.

[Steffo]

Does anyone know why he choosed wlroots over Mir? The latter is based on modern C++.