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

Martin Flöser <[email protected]>
Newsgroups gmane.comp.kde.devel.kwin
Message-ID <[email protected]>
graesslin added a comment.


  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.
  
  Present Windows as explained is in a very bad state. I blogged about this in 2013 https://blog.martin-graesslin.com/blog/2013/04/hitting-walls-a-story-of-present-windows-2/ - I recommend to read it. This was basically my answer to the feedback on the change: we hit walls and we need to do something about it. You are very much for improving the UI: please do so. Please address the issue by rewriting Present Windows and Desktop Grid through QML, but don't make Present Windows a feature and maintenance mess offering multiple ways to achieve the same.
  
  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. We have seen options being broken for years without anybody noticing. It's quite common in the effect system.
  
  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.

REPOSITORY
  R108 KWin

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

To: ngraham, #kwin, davidedmundson, broulik
Cc: kossebau, graesslin, kwin, jraleigh, GB_2, mkulinski, ragreen, jackyalcine, Pitel, iodelay, bwowk, ZrenBot, ngraham, alexeymin, lesliezhai, ali-mohamed, hardening, jensreuterberg, abetts, sebas, apol, 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.