KDE Continuing To See More Wayland Improvements, Fixes To Dolphin

[ngraham]

Alright, fair enough. Maybe he's not the lead dev, as in having contributed the most code over the years, and he's also not the maintainer, but it certainly seems like he's the leading dev nowadays, as in the guy that has stirred things up during this past half year or so and has tried to tackle the multitude of open issues that have been preventing KWin from having proper Wayland support. I'd think his "forking" of KWinFT is a testament to that.

By the way, since I've mentioned the fork: you said in your blog post that this fork makes you sad, because improving KWin should be a collaborative effort and not a one-man, solitary fight - implying that this fork is solely an initiative of Roman's. But so far, this fork seems to be anything but a fork, but rather, as I and others have already said, more of a new branch where Roman (and presumably the rest of the KWin devs) will be able to break things apart to their hearts' content in their pursuit of Wayland greatness, but without risking compromising KWin's stability and/or compatibility. I'm not sure this should be the place where such things are discussed, but... is this is not so after all?

The fork is a one-man show run by Roman. It's a fork, not an external-to-KDE development branch. Allow me to add some context:

Roman committed quite a lot of KWin code and was one of the lead developers but was by no means *the* lead or leading KWin developer. However throughout 2019 he became convinced that KWin's current architecture was unsuitable and was holding back the software's development. Over time more and more of his patches were refactoring and re-architecture work to address this perceived deficiency. This was quite disruptive to other developers as it blocked their feature and bugfixing work before it had landed, and made re-basing their patches difficult afterwards. Other KWin devs did not share his position that the current architecture was fatally flawed and needed to be fundamentally re-done, so the endless refactoring seemed unnecessary to them and caused a bit of interpersonal friction. It's not really that one group/person was obviously right and the other was obviously wrong; it was simply a technical disagreement. Not being a KWin developer, I'm not really qualified to even have an opinion on the subject, let alone agree with one position or the other. Unfortunately that disagreement could not be resolved and Roman's KWin fork is designed to showcase his ideas about what KWin's architecture should look like. Is he right? I have no idea. Maybe he is. Time will tell, if he manages to maintain his energy doing everything himself. One-man shows are hard work, and keeping up the momentum over time is a challenge. I just hope that if he is right, or if there's a lot of good stuff in his fork, that it's eventually backportable to upstream KWin.

[Volta]

How many wayland fans

X is dead and Wayland is natural choice. Nobody smart will stick to X (those who're leeching on Linux' graphic stack will catch up later, maybe, but I hope they won't).

[ms178]

The fork is a one-man show run by Roman. It's a fork, not an external-to-KDE development branch. Allow me to add some context:

Roman committed quite a lot of KWin code and was one of the lead developers but was by no means *the* lead or leading KWin developer. However throughout 2019 he became convinced that KWin's current architecture was unsuitable and was holding back the software's development. Over time more and more of his patches were refactoring and re-architecture work to address this perceived deficiency. This was quite disruptive to other developers as it blocked their feature and bugfixing work before it had landed, and made re-basing their patches difficult afterwards. Other KWin devs did not share his position that the current architecture was fatally flawed and needed to be fundamentally re-done, so the endless refactoring seemed unnecessary to them and caused a bit of interpersonal friction. It's not really that one group/person was obviously right and the other was obviously wrong; it was simply a technical disagreement. Not being a KWin developer, I'm not really qualified to even have an opinion on the subject, let alone agree with one position or the other. Unfortunately that disagreement could not be resolved and Roman's KWin fork is designed to showcase his ideas about what KWin's architecture should look like. Is he right? I have no idea. Maybe he is. Time will tell, if he manages to maintain his energy doing everything himself. One-man shows are hard work, and keeping up the momentum over time is a challenge. I just hope that if he is right, or if there's a lot of good stuff in his fork, that it's eventually backportable to upstream KWin.

Thanks for providing more context. So would the KWin upstream developers be more open and willing to accept his patches if he can show significant improvements with his fork? As a technical showcase it would have its place then. And personal frictions due to disagreements aside, it is about technology first and bringing things forward in the KDE ecosystem, right?

Maybe the KDE project should take a step back and re-think how to tackle some of the persisting issues and what the main priorities are (good old SWOT analysis), e.g. I'd weigh work on improving KWin (Vulkan backend, Freesync, tackling latency issues etc.), Wayland, CI and stability higher than some of the other niche use cases which were highlighted during the last months here on Phoronix. Losing an active developer like Roman should also raise questions how to better integrate such modernization efforts in the future without risking to alienate those developers.

[ngraham]

Thanks for providing more context. So would the KWin upstream developers be more open and willing to accept his patches if he can show significant improvements with his fork? As a technical showcase it would have its place then.

Absolutely.

And personal frictions due to disagreements aside, it is about technology first and bringing things forward in the KDE ecosystem, right?

That's how I think Roman views it, at least. Like I said, the other KWin developers were not as convinced as he was that KWin's fundamental architecture is misguided. However there is fairly broad agreement about the deficiencies of the KWayland framework, which is why it's odd to me that Roman didn't want to continue working within KDE to help forge a solution on that. My sense is that pretty much everybody agrees on its problems and what in general needs to be done to fix it (i.e. deprecate the framework and put the code used by KWin into KWin itself, so that it can evolve over time without needing an ironclad API compatibility guarantee).

Maybe the KDE project should take a step back and re-think how to tackle some of the persisting issues and what the main priorities are (good old SWOT analysis), e.g. I'd weigh work on improving KWin (Vulkan backend, Freesync, tackling latency issues etc.), Wayland, CI and stability higher than some of the other niche use cases which were highlighted during the last months here on Phoronix. Losing an active developer like Roman should also raise questions how to better integrate such modernization efforts in the future without risking to alienate those developers.

We're all well aware of our deficiencies. Roman's chief complaint on that front was that we weren't addressing them fast enough. On that subject I can't really disagree much with him, and sometimes KDE's slow pace of change frustrates me too. However this is not really anything unique to KDE; any organization big enough to matter has to move slower than a small nimble team or an individual. It's a consequence of KDE's reach and importance. Moving fast and breaking things isn't a big deal when nobody uses your stuff or your users are adventurous sorts who like living on the bleeding edge. This is not to say that we can't move faster, and we should. But promoting big changes in a large institution is a skill that involves diplomacy, patience, and the ability to upset the apple cart without upsetting the people pushing it. The lure of going it alone to move faster is omnipresent, but when you do this, one of the things that makes you able to move faster is your diminished reach and significance. KWin is installed by default on every Plasma system, which means that probably upwards of 99% of Plasma users are still using it. KWinFT, even if it gets packaged on all distros, will always have two orders of magnitude fewer users. Its users will be adventurous technical experts who file detailed bug reports and are comfortable with some breakage. But this is not acceptable for general users, which means KWinFT will have to become more stable and conservative if it ever wants to either get picked up as the default window manager in any distros, or get re-integrated into KWin itself. So ultimately its only future involves gaining the characteristics of the thing it was originally forked from! I think that all of this happening is unlikely, but hey, stranger things have happened.

[bug77]

ngraham It would be nice if you could give us a little more information about the apparently conflicting views about Kwin. If you can, of course, as you may not be aware of enough details.
I have a very vague feeling that Roman wanted to turn Kwin into a Wayland compositor that can also support X11, while the rest of the team wants to keep Kwin an X11 compositor that can also support Wayland.

[Awesomeness]

I'm hopeful that we can re-integrate Roman into upstream KWin development and incorporate some of his improvements.

If TQtC really reversed their course WRT Qt Open Source releases, Plasma 6 would be one to 1.5 years off, so not insanely long. If KWinFT turns out to be technologically superior, just take that for KWin 6.0.

[ngraham]

ngraham It would be nice if you could give us a little more information about the apparently conflicting views about Kwin. If you can, of course, as you may not be aware of enough details.

I think I just did, no?

I have a very vague feeling that Roman wanted to turn Kwin into a Wayland compositor that can also support X11, while the rest of the team wants to keep Kwin an X11 compositor that can also support Wayland.

I don't have enough technical understanding of the issues at play to comment. However as Martin wrote in his blog post, if he was writing a Wayland compositor from scratch, he would not start with KWin but rather build a whole new one from the ground up. So that would seem to throw water on the idea of KWinFT being a Wayland compositor first and blowing up X11 compatibility when necessary.

[Guest]

X is dead and Wayland is natural choice. Nobody smart will stick to X (those who're leeching on Linux' graphic stack will catch up later, maybe, but I hope they won't).

It's exactly the opposite. You are another wayland's fan (or other?).

[Volta]

It's exactly the opposite. You are another wayland's fan (or other?).

No, but you have no clue or worse. X is not developed anymore and many of it's developers moved to Wayland. Prove me wrong or shut up X fanboy. X is far from ready and bug free, but they decided to leave this crap.

[Guest]

I doubt anyone is a Wayland fan (as in, having Wayland posters hanging over their beds). It's just people that like the new and jump on that when given a chance and people who (for various reasons) value things that work more.
The "readiness" thing is a (very successful) red herring.

Except that X11 doesn't work well for many modern use cases (and even use cases that have been around for decades). The X11 developers are the ones highlighting these problems and working on Wayland.

The compositor/window manager needs more control to work correctly, and allowing any random app to access anything and do anything is BAD.