Martin Flöser Steps Down As Maintainer Of KDE's KWin

[TemplarGR]

Great news. An overrated mediocre developer/drama queen made us a favour and was self-removed from a crucial community project. That guy had more ego than code, and quite frankly he did more harm than good to KDE.

[Awesomeness]

That's the thread subject authored by Martin. You'll notice all the mails in the thread have this subject.

You asked how that conclusion could happen and I gave you an answer. Maybe KDE's Mailman setup should not strip the leading "RE:" for clarity.

[BwackNinja]

This doesn't make any sense. The developer is building a product. It might be a free product but it's still a product that people use. If an overwhelming majority of your product's users want a feature, how is ignoring them "good time management"?

I never said overwhelming majority, and that's the big point here. If someone wants a particular feature or wants something to behave in a certain way, if they aren't willing to do the work for it to get implemented, then it's up to the developer. If the developer doesn't have the the time or the interest to do it, then it doesn't get done. Part of being interested in implementing a feature is how much it lines up with your visions for the project and being convinced that a feature should be part of the vision by how people clamor for it. The big question is how do you gauge vocal vs majority? A secondary question is, when do you compromise about what you want in a project versus some subset of users? Even if you can do so and it isn't difficult, adding features can be a mistake -- whether it is for making code maintenance more difficult or driving the project in a direction you don't agree with.

Again, this doesn't make any sense. It might make sense for niche apps – say a sea diving app is going to naturally have less users than a calendar or a todo app but when comparing within the same category the number of users absolutely is an indicator of quality. Quality meaning the software product as a whole and not the "beauty" of your class hierarchy or the indentation of your code.

The way I see it, the problem of many FOSS projects is that their developers and maintainers don't treat them as products. This often directly results in disgruntled designer contributors and disgruntled users.

Again, it seems we're talking past each other here. For one, a lot of developers work on a project to scratch their own itch. Their applications are designed in a way that best accommodates what they want out of it, and does other things because other people want those things and the developer finds it interesting to implement it. If we talk about window managers, something like i3 is rather niche until you start digging down deeper into what niche it fills and who it fills it for. That's in contrast with something like KWin, which is specifically aimed at a larger population. They operate in the same field, but because of the market that they're catering towards, they have vastly different sets and sizes of users.

I'll disagree also with the idea that developers aren't treating their software as a product. The fact that they treat it like a product is evident in the compromises they don't make. A good (and relevant) discussion is this one involving Martin:

https://phabricator.kde.org/T8707

It's very clear from the discussion that Martin cares about the state of KWin and understands the caveats in implementing the initial solution as presented and the landscape of applications that have to be dealt with properly for a satisfying solution.

[ngraham]

What worries me is that be these overall look and feel initiatives do only provide visual changes to users without real improvements. Discover and system settings are the tools I really do not like to use at all, often they are broken and I do really wonder who of the devs really tested them. I mean to make something more nicer is a nice idea, and I appreciate these small efforts as well, but you should also make them work. Instead of adding new adjustments for existing functionalities, maybe just click once through the menu tree, it is easy to crash discover and system settings and the layout is often broken. How can this go unnoticed? And has it been tested on Wayland?

This is exactly why I've spent a good part of the last 6 months working with the Discover developers to improve the UI, and they've been working hard to fix the crashes and bugs. When we ship 5.13 in a few days, I think you and others will be pleasantly surprised.

In no way, shape, or form are we unaware of the criticisms or ignoring the issues. it's just easy to miss the progress if you're not following the development, which is part of the reason why I try to highlight these pre-release improvements over at https://pointieststick.wordpress.com...-productivity/

What kinds of changes or improvements would *you* like to see?

[andrei_me]

As a developer myself, I had a similar situation as described by Martin when the company that I worked for was bought by another, and the team of this company wanted to rewrite our framework, they thought they knew better than us, didn't listen to our input, in the end they wasted 3 months of work because they had assumptions/premises that were faulty

[nuetzel]

[snip]
Therefore, I want to repeat my call for specifics. Generalities aren't actionable. If you can tell me specific examples where you think we're removed features or prioritized form over function, I'm happy to take a look and see if any course correction is needed. You might find we're actually in agreement.

Hello Nate,

no offence to your GREAT commitment and maybe 'stupid' (personal) openSUSE (Tumbleweed) only question:

oxygen-transparent-0.1+20141112-6.24.x86_64
oxygen-transparent-liboxygenstyle-0.1+20141112-6.24.x86_64

packages are gone (should be removed).
What replacement do I need to have transparency stay on Plasma5?

Thanks!

[zoomblab]

My best guesses would be https://phabricator.kde.org/D12732 and https://phabricator.kde.org/D12795 given security was mentioned, and potentially, given the timing, https://phabricator.kde.org/T8707 with https://phabricator.kde.org/D13276, but that's guesses, there might be more and others. Best ask him directly? It's not like he disappears completely, just stepping down as a maintainer.

I just read the discussion regarding the "no borders" issue and I, a huble user of KDE, support 100% the VDG arguments.

[nuetzel]

[-]
Stop putting form in front of function, don't remove separators and the likes just because it makes the UI look less crowded, don't drive off developers and instead try to find compromises with them, don't make half of KDE look like mobile apps that someone dragged to the desktop (a lot of concepts just don't work with mouse and keyboard, or not as efficient) and so on, the list is very long.

So RIGHT!
STOP this 2D (swiping) shit.
We had ages of UI (lab) research.
Look up under haptics etc.
No borders. - Argh.
Konsole without 'status bar'. - Horror.
We have knobs. - Like knives & forks. Generations of people have learned how to use them...

I want to decide myself. - Or leave.

KDE user since the _beginning_ (after self compiled ol(v)wm).

[R41N3R]

I want to reassure you and others that we are NOT trying to remove features for the sake of design. In fact, we are consciously trying to keep them while also improving defaults and presentation. The new KCMs definitely look and feel simpler, which is by design, but under the hood all of the features should be still there. This project is all about UX, not removing features. The only feature I'm aware that we removed during this process was the tinting feature in the Icons KCM, because during the porting process we discovered that it didn't work and would be troublesome to fix. Apparently it has been broken for four years, and we had not gotten a single bug report about it. From this we reasoned that nobody used it, and we aw that the functionality is already basically available via other means anyway, so we felt comfortable removing the UI for it. For everything else, all the features you've come to know and love should still be there.

Our Kirigami apps have indeed been guilty of feeling too mobile-ish in the past when run on the desktop, and that's why I've been pushing fairly hard to improve that situation for the past 6 months. Compare Discover from Plasma 5.13 with Discover from 5.11, for example. Convergence means that it works well on every form factor, not that they all look like a big dumb phone app. In the cases where that's not the case, I want to know about it so I can help make it better.

Therefore, I want to repeat my call for specifics. Generalities aren't actionable. If you can tell me specific examples where you think we're removed features or prioritized form over function, I'm happy to take a look and see if any course correction is needed. You might find we're actually in agreement.

What worries me is that be these overall look and feel initiatives do only provide visual changes to users without real improvements. Discover and system settings are the tools I really do not like to use at all, often they are broken and I do really wonder who of the devs really tested them. I mean to make something more nicer is a nice idea, and I appreciate these small efforts as well, but you should also make them work. Instead of adding new adjustments for existing functionalities, maybe just click once through the menu tree, it is easy to crash discover and system settings and the layout is often broken. How can this go unnoticed? And has it been tested on Wayland? Yes, these applications improved, but that's not an excuse to leave real bugs open just because they mean more effort. If system settings would be simple text list of options, fine to me as well, as long as it works.

Martin was a guarantee, that the quality improves and that you do not play around with the basic desktop like with normal applications. I can only hope that Kwin is not the next victim of simplistic decisions, but seeing adjustments like Dolphin root window, I have a lot of doubts now.

[tessio]

That's easy but a lot of manual work to list, so I leave the exercise to the reader to just go through the current kcm redesigns and look for feature parity. That's actually a great diff view so you can see which settings got lost.

"I have no idea of what I'm talking about so I'll just dodge the question..."