KDE Continuing To See More Wayland Improvements, Fixes To Dolphin

[Nth_man]

is still developing Kmail

You can ask in the kde-pim mailing list:

https://mail.kde.org/pipermail/kde-pim/

"The [email protected] list is intended for discussing the development of KDE PIM applications, i.e. Kontact, KMail, KOrganizer, KAddressbook, KAlarm, etc."

[andyprough]

andyprough You linked the blog post, fine. You quoted irrelevant parts, not ok. Why did you do that? Is it tabu to talk about disagreements?

"taboo", not "tabu". And your definition of "irrelevant" is incorrect.

[mgraesslin]

That's expected, given Martin until very recently was the main developer of KWin and only stepped down after he disagreed with the rest of the KDE community on the state of things regarding KWin, its quality and its future as far as Wayland is concerned.

Do you have any idea how much none sense you are writing here? There has not been any disagreement with developers at all. I stepped down mostly for private reasons. Latest in August 2018 I would have stepped down anyway for private reasons. The point in time was triggered by a discussion about window decorations, where I realized I'm standing in the way. Those who do, decide. I didn't do, I should not decide. More information in my blog post about this: https://blog.martin-graesslin.com/bl...ot-a-good-bye/

It bears repeating: Roman is the current lead KWin dev, not some random guy.

Roman is not and has never been the lead KWin dev. The lead dev is Vlad. Roman has contributed quite an amount of code, but never in an amount that could qualify as lead developer. He was one of the co-maintainers after I stepped down.

[Nocifer]

Do you have any idea how much none sense you are writing here? There has not been any disagreement with developers at all. I stepped down mostly for private reasons. Latest in August 2018 I would have stepped down anyway for private reasons. The point in time was triggered by a discussion about window decorations, where I realized I'm standing in the way. Those who do, decide. I didn't do, I should not decide. More information in my blog post about this: https://blog.martin-graesslin.com/bl...ot-a-good-bye/

I certainly got a different impression from your debates with the VDG, both before and after your "resignation". And you yourself had said that a primary factor of your decision back then was a lack of motivation to continue as the KWin maintainer due to those constant, unproductive debates. But as I already said, I'm not an expert in KDE's internal politics and I acknowledge I may be completely off the mark. Especially if the debates were just incidental and there were other, private reasons that made you step down, which of course I'm not in any position to know about. Apologies if that is so. But for what it's worth, in those specific debates with the VDG (and a few others I remember as well, such as the debate on how an IME should be properly integrated in KDE; but I digress) I think you were more right than wrong.

Roman is not and has never been the lead KWin dev. The lead dev is Vlad. Roman has contributed quite an amount of code, but never in an amount that could qualify as lead developer. He was one of the co-maintainers after I stepped down.

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?

[elvenbone]

Until KDE offers a clear overview about where they are wrt Wayland support

You can always go to KDE's Phabricator page and check the state of things yourself.

Phabricator is not a cleat overview of Wayland support. It is much more, but definitely not a clear overview.
(Maybe I'm looking wrong at that tracker, since I also failed to use the search function properly.)

For example, what is the status of KWin scripts support in Wayland?

[Guest]

The exact opposite - obviously, the issue could be fixed in the current code base, no need for a fork.

Well they stated that the fork was created due to frustration with the slow pace of development in KWin. Since KWin is used to run people's desktops, they have to keep it stable and change it slowly to use Wayland and other modern technologies.

The person who forked it wanted to just go ahead and add support for Wayland, use newer C++ versions etc. without being hampered by having to support old and deprecated features.

[Guest]

How many wayland fans

[bug77]

How many wayland fans

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.

[Awesomeness]

The person who forked it wanted to just go ahead and add support for Wayland, use newer C++ versions etc. without being hampered by having to support old and deprecated features.

Just a small addition: The FT in KWinFT stands for Fast Track. Even the name itself already 100% confirms what you wrote.

[ngraham]

But I'm pretty sure this fork was made in agreement with the rest of the dev team, not in spite of them. It bears repeating: Roman is the current lead KWin dev, not some random guy.

That wouldn't be accurate. Forks don't require permission in the first place, But Roman's KWin fork was not undertaken with the consultation of the remainder of the KWin developers, though many of them and others--myself included--suspected before he made his work public that he was doing it).

I'm hopeful that we can re-integrate Roman into upstream KWin development and incorporate some of his improvements. One of his big gripes concerned tooling, which we're about to improve upon in exactly the way he wanted with the GitLab transition, which is in progress and should be completed in a few weeks.