KDE splits KWin into kwin_x11 and kwin_wayland

One of the biggest behind-the-scenes changes in the upcoming Plasma 6.4 release is the split of kwin_x11 and kwin_wayland codebases. With this blog post, I would like to delve in what led us to making such a decision and what it means for the future of kwin_x11.
↫ Vlad Zahorodnii

For the most part, this change won’t mean much for users of KWin on either Wayland or X11, at least for now. At least for the remainder of the Plasma 6.x life cycle, kwin_x11 will be maintained, and despite the split, you can continue to have both kwin_x11 and kwin_wayland installed and use them interchangeably. Don’t expect any new features, though; kwin_x11 will get the usual bug fixes, some backports, and they’ll make sure it keeps working with any new KDE frameworks introduced during the 6.x cycle, but that’s all you’re going to get if you’re using KDE on X11.

There’s one area where this split might cause problems, though, and that’s if you’re using a particular type of KWin extension. While KWin extensions written in JavaScript and QML are backend agnostic and can be used without issues on both variants of KWin, extensions written in C++ are not. These extensions need to be coded specifically for either kwin_x11 or kwin_wayland, and with Wayland being the default for KDE, this may mean some of these extensions will leave X11 users behind to reduce the maintenance burden.

It seems that very few people are still using KDE on X11, and kwin_x11 doesn’t receive much testing anymore, so it makes sense to start preparations for the inevitable deprecation. While I think the time of X11 on Linux has come and gone, it’s unclear what this will mean for KDE on the BSDs. While Wayland is available on all of the BSDs in varying states of maturity, I honestly don’t know if they’re ready for a Wayland-only KDE at this point in time.