D21083: [effects/presentwindows] Allow closing windows on middle-click

Nathaniel Graham <[email protected]>
Newsgroups gmane.comp.kde.devel.kwin
Message-ID <[email protected]>
ngraham added subscribers: zzag, apol.
ngraham added a comment.


  In D21083#463377 <https://phabricator.kde.org/D21083#463377>, @graesslin wrote:
  
  > Having some more time to write. I really do not want to see this option come back. It was the right decision to remove it, I stand to it. I had a shitload of of negative comments due to it and it would have been easy to just revert the change, but from a product development perspective it's wrong to do so. I really need to point out that this is a feature only required by a handful of very noisy and angry users. We don't have to cater to those who scream load but we need to develop a good working product with a streamlined UI and good interaction. While it's true that there are other applications implementing close on middle click, I think it's wrong to offer it on X11. Middle click has a very defined meaning as a fast way to paste. Users could expect that middle click performs a paste action and not close windows.
  
  
  You can fight the rest of the world, but you'll lose. Middle-click-to-close has appeared as an interaction method and won't go away just because it's not in the X11 spec or you don't like it. Ignoring people's changing expectations over time is a sure way for both you and your software to become obsolete and irrelevant.
  
  In D21083#463377 <https://phabricator.kde.org/D21083#463377>, @graesslin wrote:
  
  > I personally consider Present Windows as feature frozen and don't touch code since that blog post. The code base is fragile - desktop grid is even worse. Let's fix it properly by rewriting. Let's fix it by making it a script, so that users can provide variants on store.kde.org where they have their special features without having to maintain all of that in KWin. Without having space ship control UI  for something as Present Windows. Present Windows doesn't need options, but we currently offer 40 options not counting the additional options to activate it. This is ridiculous. Let's not make it worse. Please take this as my feedback as domain expert having maintained the code base for years: we took it too far, we destroyed it by the configurability. And at same time we know that users don't use these settings. Nobody knows these options exist, nobody changes them.
  
  
  Except for the people who want this option to come back. You're ignoring them on purpose, which is why they're angry. If you want to rewrite the effect, then do it. But this is production code with real users, even though you consider it fragile. As such, it deserves to be maintained, upgraded, and polished, until the time when it's replaced. But you need to choose one or the other: rewrite, or maintain and upgrade. You can't choose neither. That's just irresponsible. I'm not technically capable of rewriting it, so I'm doing what I can for the existing version. I see you doing nothing but trying to block me. If you want to help, rewrite the effect like you've been saying you want to do for the past six years. If you're not going to do it, then stop trying to make it difficult for other people to step up and maintain the existing one.
  
  In D21083#463377 <https://phabricator.kde.org/D21083#463377>, @graesslin wrote:
  
  > Last but not least a personal comment: I think it's very bad from a community perspective if changes of former maintainers get reverted once they are no longer active. Especially if these were changes where the maintainer took a hard decision and an unpopular decision. I always considered Lubos's hard decisions (e.g. usability of window decorations) as very important and did not just screw these decisions over although it caused issues with other team members, especially the Oxygen team. I think it would have been unfair to their work and passion.
  
  
  Sometimes unpopular decisions are unpopular because they're wrong. By way of illustration, you fought me tooth and nail over being able to run Dolphin and Kate as the root user (not as sudo, but as the actual root user). I won that fight over your objections, and nothing bad happened. Users are happier and no security was compromised (running in a root session is already insecure; being unable to run your file manager or text editor does not improve the situation). You were simply wrong about that. And that's fine! We all make mistakes. It doesn't mean you're a bad person or you have bad judgment. But all decisions should be subject to being re-visited from time to time, and we should have the humility to admit when we were wrong and change course.
  
  This idea of a decision that must be set in stone even after the person who made it is gone runs totally counter to the ethos of free software. It's designed to be a collaborative project that evolves over time, not a marble obelisk carved by a sculptor that must be protected from vandals for all eternity. If that's the development model you want, it's all over the closed-source world. Half the people in my last company were still on RHEL6, and I imagine there must be some team at Red Hat whose job it is to maintain that ancient software and keep it safe from the world changing all around it. I spent 10 years in that sort of environment only to realize that it wasn't the career I wanted, and I find the openness to change in FOSS communities refreshing. KWin is an unfortunate exception from my perspective, and I think it's something that needs to change for the overall health of the project. Freezing production code with no replacement and pushing away contributors who don't agree 100% with your opinions are great ways to make a project slowly die.
  
  ---
  
  We can argue forever--and I really do expect that we can; both of us seem to have very high levels of endurance for this sort of discussion. I expect that neither one of us will agree with the other on this, but neither of us is the KWin maintainer so ultimately it's up to KWin's current pseudo-maintainer (@zzag) or active developers (@davidedmundson, @apol) to decide whether they want this or not.

REPOSITORY
  R108 KWin

REVISION DETAIL
  https://phabricator.kde.org/D21083

To: ngraham, #kwin, davidedmundson, broulik
Cc: apol, zzag, luebking, kossebau, graesslin, kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, mart
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.