As the possibility to close windows in the "present window" effect via mouse bindings is no longer available in 4.11, Martin Gräßlin asked me in bug #321190 to open up a bug report against it in which I describe what the problems with the overlay buttons are. I am aware that this is not a regular bug report, feel free to point me to better places. First of all a definition of a use case: Say I have i workspaces, and m windows of a given application x (e.g.: konsole) spread over these workspaces. Now I want to close n windows out of m, where n < m (For people preferring language notation: some but not all windows of an application). So far the action was: Enable present windows for this given application (feasible both via keyboard shortcut or mouse binding on the icon tasks), then see which windows I want to close and close them. Now where is the problem to do that with the overlay? It has two main issues: 1) Possibility to close windows accidentally. This problem is actually fueled by several little problems: 1a) First of all, the position of the button is not predictable. It should be in the top right corner, but depending on the alignment it moves more towards the middle of the window (seen with smaller windows in the "Natürliche Anordnung" (natural alignment, maybe?). Hence even if you move to an assumed safe position, it isn't. 1b) Next is the size: while the size of the presented windows varies a lot (based on amount of windows, screen resolution, alignment) the close button is always the same size. This can make it quite big compared to the "safe" area of the window With these two combined I was able to accidentally hit the button in a, I have to admit, experiment with lots of tries. However, even once is too much, as, depending on the application, this is a not revertible action. Now with that added delay there comes the second issue: 2) Amount of time needed to fulfill the task. As per fitt's law, one knows (and can calculate) that pointing is quite time consuming and hence, especially for repetitive tasks as this is, should be avoided if possible. Also here there are the same problems as mentioned above: moving target and size. Doing a few measurements even with some practice it took me a bit more than two point five times the amount of time to achieve the same goal as I had to before. Now one could argue that, due to re-sorting of the windows mid-effect, pointing is needed anyway. Yes, it is. However, there are two problems: 2a) the area of the window is much bigger and hence it is easier (and faster) to hit 2b) As for closing both types of mis-aiming are unwanted: in case of missing the button when the user wants to close the window, the effect (in the default settings) ends, as the window is activated. In the case of not wanting to close the window the consequences are even worse. Hence the user has to make sure that his aiming is correct, which increases the time it takes (checking) In addition to that, the delay can be quite annoying as you clearly are on the button, click, yet nothing happens. This is unpredictable behaviour. In addition to that the following arguments for the buttons where: "closing windows from PW is an outstanding task (since hitting the close button is not harder than hitting any button in a toolbar)" While the latter is correct, the former isn't. It is based on the assumption that this task is to be compared with tasks who require hitting a button. It isn't, as there are quicker ways to close a single window, including keyboard shortcuts. This also leads to the second argument: the use case being void. The problem here is: this was the only usable tool to achieve the task of closing n out of m windows. Because the other tools have the following issues: 1) Using the close button or keyboard shortcuts: very slow, especially if the windows are spread over workspaces. Also it requires a mouse/keyboard switch, which is the most time consuming action. 2) Using the context menu in the task manager: doesn't provide previews, so if the titles of the windows are the same (as in the example of konsole: quite a lot the case) it is harder to find out which windows you want to close 3) Using the (x) button in the taskbar previews (not available on all task manager plasmoids, afaik): the preview is much smaller so it is harder to know which windows are the correct ones, in addition of using quite a lot of aiming. Now how can these issues be addressed? In my opinion not with overlay buttons. Whenever you try to improve one aspect (speed or safety) the other will suffer (examples: change button sizes, change timeout / prevention of accidentally clicking the button). Are buttons bad in general? No. They make sense in a touch environment (even though I don't know how the "only show when window is active" works there, this could be a pain. Shall try next time I get a PA device to play with). But in a mouse and keyboard environment they are, as per the reasons above, inferior. A nice solution would be the mentioned change which would allow selecting n windows (as in: CTRL+Click select) and then choose an action. However, there are a couple of issues: 1) this is not available yet 2) These bring a few more questions along, e.g. how to implement on touch devices. A + overlay similar to files in dolphin could be used. But then how to you choose the action? Also: should the close button still be visible on a single window? If yes: what does it do when multiple windows are marked and it is clicked. So things like context menues (careful with regards to Hicks' law, also won't work well on touch) or action lists (works well on touch, less on mouse + keyboard) or keyboard shortcuts (no visual indication for a destructive action) could be used. But then that is something that shouldn't be discussed here, I guess. Sorry :) So: I know this is not a regular bug report. If anyone has good ideas to address the above mentioned issues so that the overlay buttons are a good alternative while the other possibilities are gone until KF5: it would be nice to hear them and see them implemented. Right now I don't have any, I shall add them when they come to mind. Kind regards Christian Reproducible: Always
Created attachment 82024 [details] Draft for QML based Present Windows Thanks for the long feedback. As I understand the two main problems here are: * natural sorting and the implied variance in size * workarounds to make the first problem less a problem (disabled button at start, etc) This is not really something news as you can see with the workarounds. Attached I have the QML script which is a starting point for Present Windows 2. If you have time for it, please give it a try (just copy into your kwin source tree in scripts folder then CMake should pick it up) and provide some feedback whether that approach fulfills the closing task in a better way.
(In reply to comment #1) > Created attachment 82024 [details] > Draft for QML based Present Windows First of all: thank you. As mentioned on IRC, just putting it in the scripts folder before compiling didn't magically add it. So if someone else faces the same problem: it is sufficient to copy the folder into the kwin script folder (/usr/share/apps/kwin/scripts on my gentoo system) and the metadata.desktop as /usr/share/kde4/services/kwin-script-presentwindows.desktop then run a kbuildsycoca4. > Thanks for the long feedback. As I understand the two main problems here are: > * natural sorting Sort of. Actually natural sorting is just a very good way to show some problems better, as they are worse there. I personally don't use it, but I think it's the default, so I tried working with defaults here. > and the implied varidesktopchangeosdance in size > * workarounds to make the first problem less a problem (disabled button at > start, etc) > > This is not really something news as you can see with the workarounds. Yes, indeed. Also I think we discussed some of these problems already when you implemented the overlay buttons, at least I remember me protesting and making a silly bet (on accidentially triggering it) > Attached I have the QML script which is a starting point for Present Windows > 2. If you have time for it, please give it a try (just copy into your kwin > source tree in scripts folder then CMake should pick it up) and provide some > feedback whether that approach fulfills the closing task in a better way. Right, some feedback (I know it's a pre-alpha as you told me on IRC, so I am entirely sure that some things will improve. Still I add them here, just to make sure they are known) There are some minor regressions, mainly the filter is almost not visible (it is a big centered overlay with the effect, here it is an easy to miss checkbox on top). There are some bugs, as an example I managed to have the close buttons covered by the task bar. There are areas which need work (e.g. user-friendly configurable etc.) but that is really probably just because pre-alpha The buttons now react immediately and given that they are always visible, the user _should_ not accidentially push them (well, at least he sees what he does. It is still possible, mainly if you move from a window that is below the one you want to select upwards). Aiming still takes too much time. So while it does have some improvements, I am still quite sure that some issues (aiming, which means it takes longer and is more prone to hit the wrong thing) simply can't be resolved with buttons, so I doubt that this will change. However, scripts do offer flexibility and can be adapted by users, so it is nice to see that all of this is possible via scripts. While this could be a nice solution for the meantime (since scripts can be delivered aside from any freezes or releases), I think that the main focus should be the new solution (multi-selection), which needs to be done right. If some good additions or fixes come to mind, I shall modify the script and upload it here. Again, thanks for your work. Kind regards, Christian
iirc the closebutton doesn't usably work on touchdevices at all - there's a patch on RB (which likely does no longer apply clanly) to change that (turning first "click" into selection only in "touch" mode) a second solution could be a global "xkill/close" toggle button, which freezes layout, turns the cursor into a close indicator and closes every subsequently clicked window. i will argue that such change is little invasive and does not require new strings, so *could* be added to the KDE4 cycle - but that's martin's take alone and i will not question his decision.
I also lack this feature. Middle click for closing in present windows was very natural and comfortable.
First of all: I miss this feature, too. Really! Every day, when I use my laptop with a mouse connected, I miss this. Because I have loads of open windows, on different workspaces, and from time to time I want to have an easy way to clean up after a few days of work. Show all windows, this is not needed anymore, that too, click, click, click and so on. Middle-click any window in the overview would be the PERFECT solution to solve the job. First of all, I wanted to open a wish-suggestion-report to add this feature to KDE. But sadly I discovered this discussion. This argument. These opinions. Full of emotions. Full of hate. Full of childish behavior. I've studied computer since, and after reading all arguments concerning this issue, I'm really worried. Worried about Martin Gräßlin arguments. @Martin Gräßlin: You said (in the in #1 linked report): "Sorry wontfix. As can be seen in the review request the action is seen as destructive and has been removed deliberately as there is an explicit action to close a window. Re-adding would introduce the same problems which were the reasons to remove it." Using that argumentation, you should ban "rm -rf", too. Why to remove files forced recursively, if you could remove them file by file explicit using their file names, and use rmdir to remove empty directories? BTW: middle-click on any title bar closes the window, too. And that is something that is not configurable. To be honest, I'm disgusted by your comment: "I don't think I have to justify the decision. The feature had been added by me (9551c94e7c460efb3b0fd9ccb60472311ff0bf16) in the first place and it has been removed by me (f2b7ad693e8c4ef59093287473fb07a3098775bc)." Well, KDE is free software. Yes, this feature had been added by you, but it is NOT your right to remove it without any justification, just becouse you don't like it. If you don't like it, your arguments should be strong enough to survive any discussion. And if not, your arguments have not been strong enough. This is what I mean with childish behavior. "This is my toy, and if I want to remove it I can remove it and it is mine so I don't I have to justify why I destroy it". Disgusting. Really. THIS is destructive behavior, form you. Destructive behavior to the spirit of free software. To give, not to destroy! It should be the users choise to enable this. It is the philosophy of any UNIX software to allow the user to do everything (destructive) he wants to do. Teading the other bugs and discussions, it seems as this is some kind of private argument between Martin Gräßlin's private opinions and the rest of the user base. Unfortunately the argumentation was with full of emotions. Personally, I'm worried if I read in any free software an argument that says "I've gave it to you so I can remove it whenever I want". That is destructive, indeed. Back to topic: Any environment, where KDE can be run, is a native multi-user environment. So every user can (and must) have its own account, settings, configuration - even if it is just a guest account - and sould be able to configure its behavior as he wants to be. And if I want to be able to middle-click-close a window, you should leave this decision to me. "I don't think I have to justify the decision." is the thing, that is destructive to anyone that uses KDE. Because it makes KDE a plaything of some contributors. Something you cannot rely on. Do you want to be KDE to be something you cannot rely on? Because features are removed because of personal opinions without justification or discussion?
The ability to close the window with a middle-click was re-added a while back, and the new QML-based Present Windows effect retains that.