Bug 321252 - Regression: no more close window mouseshortcut in present window effect
Summary: Regression: no more close window mouseshortcut in present window effect
Status: RESOLVED DUPLICATE of bug 321190
Alias: None
Product: kwin
Classification: Plasma
Component: general (show other bugs)
Version: 4.10.80
Platform: Gentoo Packages Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords:
: 322976 (view as bug list)
Depends on:
Blocks:
 
Reported: 2013-06-17 07:55 UTC by Christian (Fuchs)
Modified: 2013-07-30 08:40 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Christian (Fuchs) 2013-06-17 07:55:59 UTC
(Related to https://bugs.kde.org/show_bug.cgi?id=314393  but it felt wrong to comment there, since imo the removal is a new problem. Sorry if I missed any dupes, I couldn't find them) 

As just discussed with Martin Grässlin on IRC: 
In 4.11 the mouse button binding for closing a window has been removed silently, leaving only the optional close button as an alternative. 

I have been given a few arguments on the why and how, so I'd like to discuss them here to give some feedback and give my POV on why I think this is a regression and should be reverted within the next 4.11 release: 

1) There is the close button overlay. Yes, there is, and I had this discussion with Martin in the past. Usabilitywise the close button is bad due to two reasons. First of all there is Fitts law (which is usability basics), which tells us that mouse pointing is one of the most time consuming actions. This is also why people use corners and similar hot spots. Forcing the user to do detailled aiming greatly reduces efficiency and makes basic tasks take more time, which is a pain for power users. Second argument, and as far as I remember our last discussion on the subject this is why the buttons where made optional, it can be triggered acidentially, since it takes the regular action (single left mouse click) to do something different depending on mouse position. and changes it to a destructive, sometimes not-revertable action. 

2) We don't want hidden destructional functionality. Now this one is wrong on many levels. First of all: it is not hidden. There was a GUI option for it and the default was unset. If you want to remove _not hidden, user configurable_ destructive functionality, you'd have to remove the keyboard shortcut (even less hidden imo, and comes with a default set), the doubleclick-on-menu-button, as far as I remember (no KDE here at work) the functionality in icon-tasks and more.  Then: there is hidden destructive functionality all over KDE. Ever tried middle clicking a tab? To be consistent you'd have to remove that as well. 

3) http://xkcd.com/1172/  (yes, this was given to me as an argument): This is also wrong on a few levels. First of all this removes "functionality" that is clearly bad. Closing a window is not bad, it is actually a task the user wants to accomplish. Accidentially closing a window is bad, but see argument 1) and 2) on that. It was user configurable with, as far as I remember, no default set. Hence if a user did use that functionality, it was on purpose. 
In addition to that: there is a difference between breaking workflows for a good reason and breaking workflows because the developer has a different viewpoint. This is why things are configurable. If the user prefers his workflow, he can just set it. This is one of the major strenghts of KDE, which makes it usable for a wide variety of users, from new-to-computer users to power users. 
I would understand if (especially hidden) functionality is removed due to technical reasons. Old code, hard to maintain code, it being bad usability wise etc. But this is exactly why I asked first why it was removed. None of this seems to apply. 

4) It will be replaced with something else in the future (5.*): well, this is nice to know, but why removing the functionality already, then? Especially in something that is considered (yes, not the applications, but workspaces) a long term release, this leaves users who use this functionality a gap for quite a long time. It could have been removed at this time, then. Since there currently was no urgent reason to remove this at all. 

As an additional argument from my side: 
The "silently" part is especially a problem because if the user previously had configured this action, it simply "stops to work" after an update to 4.11 with no information for the user at all. This is, from a usability point of view, one of the worst things to happen and quite likely will produce bug reports (and duplicates) which causes additional work. 

So, short:  a user configurable, non hidden functionality was removed silenty for non-technical reasons, the provided alternative is worse in a usability way and there are plenty of other things that, according to the argumentation, should have been changed if it really was an issue. 

Please do not only revert this, but do think twice in the future before breaking user workflows by removing functionality that you may not use. 

(As a minor sidenote: one of the reasons given why this can't be reverted was "string freeze". While I do see the issue that the translators need their time to finish work so it is ready when the release is, this makes it very hard for people who do install the betas / RCs on their machines and provide you with bug reports and feedback. Maybe the workflow should be adapted there so that string freeze is after the first public beta, so that string-freeze breaking bugs can still be fixed.) 

Thanks for considering this and for your work on KDE / kwin. 

Reproducible: Always

Steps to Reproduce:
1. Update to 4.11
2. Try to close a window with a mouse button that you previously configured
Actual Results:  
Nothing happens, user is confused, user goes to settings and notices that there is no close action anymore. 

Expected Results:  
Works as expected. 

Example usecase for this functionality: 

You have n windows of a given application x, take konsole as an example, spread over m workspaces. You'd like to quickly close i out of n, where 1 < i < n. Present windows was the most efficient way of doing so, especially since it provides a "only windows of application x" mode.
Comment 1 Christian (Fuchs) 2013-06-17 07:57:50 UTC
*sigh* duplicate of https://bugs.kde.org/show_bug.cgi?id=321190. Now why  "kwin close"  "kwin present windows close" and several other queries didn't find that one ... Sorry.
Comment 2 Martin Flöser 2013-06-17 08:38:26 UTC

*** This bug has been marked as a duplicate of bug 321190 ***
Comment 3 Martin Flöser 2013-07-30 08:40:43 UTC
*** Bug 322976 has been marked as a duplicate of this bug. ***