The possibility to bind "close window" to a mouse button in present windows effect was removed in KWin 4.11. This allowed an incredibly efficient way to kill unneeded windows as you could do it with a single mouse click without needing to find the close button (small hit zone). It would be awesome if this feature could be added back if not even made the default (bind to the right mouse button. Reproducible: Always
https://git.reviewboard.kde.org/r/108851/ https://bugs.kde.org/show_bug.cgi?id=314393 - see comment #1 FTF, please use less generic subjects - esp "regression" in a wishlist entry is rather confusing ;-) Thanks
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. Obviously making it the default is completely out of bounds as it is a destructive action. I'm sorry that this is causing inconveniences to you but we have to design software in a way that all users can use it properly. The Present Windows effect is going to be rewritten in QML in future which should allow to easily fork the component and add the actions.
I'm curious; how was it evaluated that the feature was destructive? A person who first of all bothers to dwell around KWin settings and deliberately changes a setting so a right click closes a window in present windows mode knows exactly what s/he is signing up to. Then most productivity applications also have a close confirmation window (and applications with multiple tabs) and many even implement autosave. The potential destructiveness seems very limited. Also there doesn't seem to be any general rule that destructive settings should exist as you can for example disable the previously mentioned confirmation dialogs. Android immediately came to my mind, applications are closed by swiping the window in the "present windows effect". It's so quick that it's actually easy to close windows you didn't want to and loose state (with some applications anyway). It's still the best possible behavior because it's important that you can easily and quickly close windows. The problem with the new behaviour is that it's too slow to be useful. The even more unfortuante part is that there's now no quick way to selectively close multiple windows- Anyhow it's nice to hear that there's potential fix (I originally though that the feature was lost because of a QML port). Thanks.
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).
(In reply to comment #3) > I'm curious; how was it evaluated that the feature was destructive? Not the feature, the action. Closing is irreversible, thus destructive by definition. > Android immediately came to my mind Android is a phone OS with totally different usage scenario and input "devices" (ten little stubs - for most ppl.) > important that you can easily and quickly close windows. Alt+F4 > The even more unfortuante part is that there's now no quick way to > selectively close multiple windows I'd personally claim that argument moot, since closing a window always has re-arranged the PW grid, so you had to redetect and approach the next window after each step. A fast way would be to mark multiple windows (eg. using ctrl/shift modifiers as common in itemviews) and then press a close button. That would also be an explicit and advertised action and less error prone (accidental MMB clicks on touchpads etc.) Thoughts on such approach to the problem?
(In reply to comment #4) > I don't think I have to justify the decision. Of course you don't... I wasn't exactly demanding anything either; I emphasized that I was curious. Now I have to wonder if I did something wrong to warrant such defensiveness. (In reply to comment #5) > I'd personally claim that argument moot, since closing a window always has re-arranged the PW grid, so you had to redetect and approach the next window after each step. The brain is pretty damn quick are recognizing that stuff. Speaking from personal experience. (In reply to comment #5) >Alt+F4 That works only if you need to kill the present window. It's not uncommon that I have fifteen or so windows open on a desktop. I want to keep maybe five of them and close the remaining ten. Closing windows with Alt+Tab + Alt+F4 (or Meta+R as I have binded it) is unconvenient. (In reply to comment #5) >A fast way would be to mark multiple windows (eg. using ctrl/shift modifiers as common in itemviews) and then press a close button. That sounds like a great solution. Especially if the windows could be marked with the mouse (right/middle click) as present windows effect is mouse oriented and it's nice to be able to everything with one input device.
See resp. wishlist item, bug #321236
*** Bug 321252 has been marked as a duplicate of this bug. ***
(In reply to comment #6) > (In reply to comment #5) > >A fast way would be to mark multiple windows (eg. using ctrl/shift modifiers as common in itemviews) and then press a close button. > > That sounds like a great solution. Especially if the windows could be marked > with the mouse (right/middle click) as present windows effect is mouse > oriented and it's nice to be able to everything with one input device. I almost agree, it in my opinion doesn't "fix" argument 1) mentioned in https://bugs.kde.org/show_bug.cgi?id=321252. As argumented over there, this is in my opinion a sad loss of functionality, so until this new method is there, it would of course be nice to have the old one back. Not for 4.11.0 due to string freeze (also see other report), but maybe for 4.11.1 Thanks :)
(In reply to comment #9) > so until this new method is there, it would of course be nice to have the > old one back. Not for 4.11.0 due to string freeze (also see other report), > but maybe for 4.11.1 The string freeze holds for the entire minor version, ie. 4.11, ie. until "5" since workspace is now "frozen" until then.
(In reply to comment #10) > > so until this new method is there, it would of course be nice to have the > > old one back. Not for 4.11.0 due to string freeze (also see other report), > > but maybe for 4.11.1 > > The string freeze holds for the entire minor version, ie. 4.11, ie. until > "5" since workspace is now "frozen" until then. Bleh. Well, for me it is trivial to just revert said commit, since I have to compile from source anyway. I was hoping to find a solution which works for everybody. Oh well, I guess we have to live with that then. It would be awesome if feature removals like this would be avoided in the future, and, as written, if bug reporters would have a chance to report bugs which are fixable before string freeze (e.g. public beta before string freeze), but this is the wrong place for this discussion. Thanks for the information.
> It would be awesome if feature removals like this would be avoided in the > future, feature removals are sometimes necessary. We shouldn't back away from them just because some people might not like it. > and, as written, if bug reporters would have a chance to report bugs > which are fixable before string freeze (e.g. public beta before string > freeze), but this is the wrong place for this discussion. This is a valid point, I will try to remember when we setup the release schedules for $whateverafter411 that we have at least one public beta before string freeze
(In reply to comment #12) > > It would be awesome if feature removals like this would be avoided in the > > future, > feature removals are sometimes necessary. We shouldn't back away from them just because some people might not like it. Yes, yes they are, but in this case I really don't see one valid argument justifying a change that has such an impact (see below). See the argumentation in other report. If you ever feel like it I'd like to discuss the points with you on IRC (or better: with a beer in real life) in detail. This is made worse by the fact that, which is something I wasn't aware of, the freeze basically means that users now have to live with this for years, given 5.0 is a bit far away. For decisions that have such a long impact it would be very nice if a discussion with the userbase could have been possible first. > > and, as written, if bug reporters would have a chance to report bugs > > which are fixable before string freeze (e.g. public beta before string > > freeze), but this is the wrong place for this discussion. > This is a valid point, I will try to remember when we setup the release > schedules for $whateverafter411 that we have at least one public beta before > string freeze Great, thank you very much :) As mentioned, for me it is not a huge issue, since the revert is just a few lines patch that I can automatically have to apply given I use gentoo. A lot of users, however, won't have this possibility and they are basically stuck with this for a while now.
@tehomail Its not really the same with android though. With androids multitasking model "closing the window" does not really "close the application", so the action is not the equivalent level of "destructible".
I have to second this. It's unfortunate that it's been marked "wontfix". I requested this feature on Brainstorm years ago, as it was the only thing stopping me from using KDE as my daily driver. I do not use a task bar, this feature is how I close applications. It's much more efficient for me than mousing over some small button and clicking it. I like having the large target to slap my mouse around and close windows quickly. Obviously it's the decision of the developers, but this is disruptive enough that I'm considering rolling my station back to KDE 4.10. I know it's whiny, but it's as obnoxious to me as removing the close button in the titlebar would be for other people.
*** Bug 323670 has been marked as a duplicate of this bug. ***
Removing this option totally makes no sense. It was a very useful option and was not a default setting -- hence this cannot be destructive in any way. The reason why I use KDE is because of it's high configurability unlike other DEs. Removing features in this way will only lead to an oversimplification and restriction. > Middle mouse clicking on a Presented Window in Unity/Compiz closes the window by default. If Ubuntu -- a distro dedicated to simplicity and ease of use decided to accept that behaviour as default in their Unity, I have no idea how someone came up with the idea of this being "destructive".
people I hope you are aware that whining as in comment #17 will not help anything. This is not a competition of who can scream the loudest will get the feature back. As a matter of fact I know that Fuchs has a patch to re-add the feature. So maybe Fuchs could attach the patch here so that people who need it can recompile KWin with this patch or ask their distro to include it. And if you don't see why this is an unpredictable and destructive behavior I cannot really help you. I have to ask you to trust me on that one and I as a dev working in that area for years think that I know more about it. So yes you configured it, but what if a friend who doesn't know about it uses your computer?
(In reply to comment #18) I am trying to not start a discussion here, but a few things are quite hard to left uncommented: > people I hope you are aware that whining as in comment #17 will not help > anything. This is not a competition of who can scream the loudest will get > the feature back. Saying that a user given actual arguments on why he doesn't see it as destructive is "whining" is a very harsh approach towards ones users. It is hardly objective and destroys the possibility of a constructive dialogue right away. > As a matter of fact I know that Fuchs has a patch to re-add the feature. So > maybe Fuchs could attach the patch here so that people who need it can > recompile KWin with this patch or ask their distro to include it. My patch has the silly rename in it, and without it: people can just download the diff with the button at https://git.reviewboard.kde.org/r/108851/ and apply it with patch -R. The main problem with this is that most of your users do not compile kwin on their own, but rather use what their distribution provides. Including a single patched package there is a huge pain for regular users, as one has to use whatever the distro offers to get the source package including all their packages, patching and hopeing that the patch still applies, compiling, installing and telling the package manager it's there. If this was in the default package then people wouldn't have this problem. > And if you don't see why this is an unpredictable and destructive behavior I > cannot really help you. I have to ask you to trust me on that one and I as a > dev working in that area for years think that I know more about it. From a usabilty POV, as described in my previous comments: either you see it not as destructive, or you have to remove a whole lot more things in KDE, including kwin. > So yes > you configured it, but what if a friend who doesn't know about it uses your > computer? That argument is completely silly, because that would mean that _all_ possible configurable destructive actions, such as keyboard shortcuts, have to be _removed_ (not even default-disabled, because that's exactly what this option was). As an example: the windows-known ALT+F4 keyboard shortcut doing completely different things on different systems. In addition to that: closing via middle click is a well known thing from other applications, such as webbrowsers (Tabs). So with all due respect: that argument can hardly count at all. If you as the developer who introduced the functionality think that it should be removed: fine, that is your perfectly valid decision. But please don't try to find arguments for it which are completely invalid and definitely please do not attack users who just wish that feature back. As much as it hurts saying this as a software engineer: when your users not only complain because of a change but even bring arguments, you should listen to them. Or at least not be rude, because it might be that they are (partially) right. Kind regards Fuchs
sorry, I didn't want to sound rude and will instead point to the code of conduct: http://www.kde.org/code-of-conduct/ Especially I want to highlight "Respecting other people, their work, their contributions and assuming well-meaning motivation will make community members feel comfortable and safe and will result in motivation and productivity.". I saw parts of comment #17 violating this. I should not have reacted with calling it whining and I apologize for it. I have to point out that it is important to keep to the CoC in such a discussion. If I as a developer feel personally attacked (and I did that) the chances that I with the maintainer hat on will revert my patch goes down and not up. Bringing arguments like "will lead to oversimplification" or the "gnome-ification" result in the same. I find these arguments as offensive against our friends from GNOME and by that destroy any possible pro-argument. So be constructive and keep to what matters. What Ubuntu does for example, doesn't matter. Especially the usage of middle click to close is totally irrelevant as middle click has a well defined behavior on the X11 platform (there was recently a discussion about that in the context of browsers on kcd). Given that I cannot see any pro-argument in comment #17. Sorry.
(In reply to comment #20) > [...] Heh, now I feel bad. Not intended *hugs* Anyway: > Especially the usage of middle click to close is totally irrelevant as middle click has a well defined behavior on the X11 platform (there was recently a discussion about that in the context of browsers on kcd). Yes and no. In an area with pastable data it indeed is supposed to paste the content of PRIMARY X SELECTION. However, in many other areas it does completely different things, including closing the thing you click on. This is found all over KDE, browsers are not the only component doing that. A quick 2 minutes search at least gave me a file browser, a text editor, an IRC client and a mail client. I have to mention that inside of KDE it is not consistent though, because konsole, as an example, doesn't do it. Even worse in kate, where one tab extension closes a tab and the other does a colour change ... Short: I wouldn't call the middle click action being well defined, but at least many (known) applications do indeed use it for closing. Just my 2 Rappen. Kind regards, Fuchs
The issues with the behavior were that a) the middle button is usually used for entirely different -and non destructive- operations (paste) b) you got no indicator for the close operation c) the environment (window selection) seems completely harmless There's a way to close windows from PW which fixes a) and b) - c) remains "choice of sanity" The "drawback" of the closebutton and the only argument to re-add the MMB closing is that the button has a smaller hitarea. This would only match the scenario where closing windows from PW is a repetitive action, ie. mass closing - which is however affected by resorting the grid after every close - a really "fast" action isn't possible in the first place. => There're valid concerns about the feature, the benefits (beyond granted but subjective "got used to it") are neglectable and the feature could not be re-added before the next major release, therefore i recommend to drop the "got used to it" aspect and this bug in favor of the solution proposed in bug #321236 - iow, I personally consider any discussion on this bug as pointless and wasted time. It's highly unlikely to talk this out of WONTFIX with a superior solution in sight.
(In reply to comment #22) > The issues with the behavior were that > a) the middle button is usually used for entirely different -and non > destructive- operations (paste) Correct. The same applies to other applications though, and users by now are used to closing things via middle click, definitely more common (as platform independent) than pasting. > b) you got no indicator for the close operation You have that neither for a keyboard shortcut > c) the environment (window selection) seems completely harmless The shortcut works in almost all environments. > There's a way to close windows from PW which fixes a) and b) - c) remains > "choice of sanity" > > The "drawback" of the closebutton and the only argument to re-add the MMB > closing is that the button has a smaller hitarea. Which is quite a huge drawback, quite common usability stuff (fitts' law etc.) > This would only match the scenario where closing windows from PW is a > repetitive action, ie. mass closing - which is however affected by resorting > the grid after every close - a really "fast" action isn't possible in the > first place. Not entirely true, as first of all this depends on the configuration of the effect plus you probably forgot about the possibility to use the effect only for a given set of windows (e.g. specific application or workspace) where it can make a lot of sense. Using it for closing n out of m windows, where m is the amount of all windows (and > n) is indeed debatable, but it's not the only usecase. > => There're valid concerns about the feature, the benefits (beyond granted > but subjective "got used to it") are neglectable and the feature could not > be re-added before the next major release, therefore i recommend to drop the > "got used to it" aspect Which, from an usability POV, is quite a critical mistake. > and this bug in favor of the solution proposed in > bug #321236 - iow, I personally consider any discussion on this bug as > pointless and wasted time. It's highly unlikely to talk this out of WONTFIX > with a superior solution in sight. It might not bring a solution for this specific bug, but it might have an impact on similar future decisions, including in kwin. (Both with respect to if one should remove features, how, and when) Kind regards, Fuchs
> > The issues with the behavior were that > > a) the middle button is usually used for entirely different -and non > > destructive- operations (paste) > > Correct. The same applies to other applications though, and users by now are > used to closing things via middle click, definitely more common (as > platform independent) than pasting. and that's wrong. I would love to fix where middle click is close and it should be paste. Most interestingly the browsers where it should be "load the pasted url". This could also be interesting for Present Windows and the middle click to just paste the current selection into the window. > > > b) you got no indicator for the close operation > > You have that neither for a keyboard shortcut which is a problem. Over the last weeks it happened a few times that I closed the browser by doing Ctrl+A followed by Shift + Q (searching in qt docs) and seeing my browser close as I hit ctrl+q. So yes that's a problem. We shouldn't dismiss valid arguments by pointing to "but there it's broken, too". > > > c) the environment (window selection) seems completely harmless > > The shortcut works in almost all environments. see above > > => There're valid concerns about the feature, the benefits (beyond granted > > but subjective "got used to it") are neglectable and the feature could not > > be re-added before the next major release, therefore i recommend to drop > > the "got used to it" aspect > > Which, from an usability POV, is quite a critical mistake. -> http://www.dgsiegel.net/news/2013_07_27-on_why_removing_features_makes_people_unhappy > > > and this bug in favor of the solution proposed in > > bug #321236 - iow, I personally consider any discussion on this bug as > > pointless and wasted time. It's highly unlikely to talk this out of > > WONTFIX > > with a superior solution in sight. > > It might not bring a solution for this specific bug, but it might have an > impact on similar future decisions, including in kwin. (Both with respect > to if one should remove features, how, and when) Well yes, it has impact on similar future decisions, because it means I will say more often "no" to adding features. A feature which is not there in the first place cannot lead to discussions when you realize that it was wrong. Yes it was wrong that I added that feature in the first place. We even knew it back then, because that's the reason why we have all the other actions. We also knew that we are not a tiling wm, nevertheless we accepted the patches. Both clear mistakes, both resulting in hated discussions when you remove it.
(In reply to comment #23) > used to closing things via middle click, definitely more common (as platform > independent) than pasting. It got common among browsers. And browsers (well, esp. FF, which i happily blame for this debatable bahavior) use the MMB equally to create and close tabs. Really: if you click into an empty area of the tabbar, you get a new tab; if you miss it by a pixel, you just closed one. Even if users would be used to do this (my experience says that non-lilnux users hardly know there's more than one mousebutton - or that one can actually close tabs) the behavior does not sound very sane to me. And it's certainly born on Windows and a questionable deviation on X11 (you do not even get a url pasted when clicking into an empty area) and KWin does not operate on other platforms. > You have that neither for a keyboard shortcut No keyboard shortcut has any indicator for anything. It's a completely different (and much older) input concept. > Which is quite a huge drawback, quite common usability stuff (fitts' law > etc.) Fitts law (what "etc."?) is only part of the calculation. (The other part is finding your target) Huge implies this is a common and repeating action. See below for probably better alternatives in that case. > Not entirely true, as first of all this depends on the configuration of the > effect plus The amount of re-arrangements depends on the configuration (regualr grid) and the amount of windows (the less windows, the more often you get them re-arranged), yes. Still happens pretty often - esp. on reasonable window amounts. > Using it for closing n out of m windows, where m is the amount of all > windows (and > n) is indeed debatable, but it's not the only usecase. So you're using it for the (regular?) requirement to close all non-minimized windows or those of the current VD or the current application? -> I'd rather consider a short script and a shortcut or pkill if I'd do that more often. > > therefore i recommend to drop the "got used to it" aspect > Which, from an usability POV, is quite a critical mistake. The recommendation pointed the reasoned unreasonability of this discussion, i frankly dare to doubt that it contained a mistake (and hope you didn't really mean that it was one)
(In reply to comment #25) > (In reply to comment #23) > > > used to closing things via middle click, definitely more common (as platform > > independent) than pasting. > > It got common among browsers. > And browsers (well, esp. FF, which i happily blame for this debatable > bahavior) use the MMB equally to create and close tabs. > Really: if you click into an empty area of the tabbar, you get a new tab; if > you miss it by a pixel, you just closed one. I don't know the windows configuration, I think given the odd tab position there it is different. But: my Linux FF has a "new tab" button right to the tab list, which works via left button. Because I definitely agree that a "create new tab" and "close tab" action should never be that close to each other. However, this is slightly off-topic, sorry. > Even if users would be used to do this (my experience says that non-lilnux > users hardly know there's more than one mousebutton - or that one can > actually close tabs) the behavior does not sound very sane to me. > And it's certainly born on Windows and a questionable deviation on X11 (you > do not even get a url pasted when clicking into an empty area) and KWin does > not operate on other platforms. Which, sidenote, is a shame. As the Windows window management is horrible. I know there are blackbox based replacements, but they only work so-so. Having kwin would be very nice. > > You have that neither for a keyboard shortcut > No keyboard shortcut has any indicator for anything. > It's a completely different (and much older) input concept. It's about as destructive, and given Martin's "not your computer" argument, keyboard layouts and the fact that Linux has over a dozen window managers: even worse. > > Which is quite a huge drawback, quite common usability stuff (fitts' law > > etc.) > Fitts law (what "etc."?) Meyers law as an example, but in general there are several UX aspects involved here, aside from just time to achieve a task, possibility to miss target and destructive, not undoable actions. (Such as habit, workflows ...) > is only part of the calculation. (The other part is > finding your target) > Huge implies this is a common and repeating action. See below for probably > better alternatives in that case. I do know that there are better alternatives. The main problem here is that they are not available for quite a long time, unless this is seen as a bug fix instead of a new feature. One possibility, which I already wanted to reply to Martin before I got distracted, would be offering people to do such things via the (rather good, from what I got) scripting interface of kwin. That also solved/will solve other issues such as tiling, hopefully. I am sure there are others, my main issue (note that I, as Martin pointed out, do patch my kwin to have the functionality again) is that the bigger part of users don't have any of these possibilities in the near future, plus the timing and arguments where, in my opinion, less than optimal here. > > Not entirely true, as first of all this depends on the configuration of the > > effect plus > The amount of re-arrangements depends on the configuration (regualr grid) > and the amount of windows (the less windows, the more often you get them > re-arranged), yes. > Still happens pretty often - esp. on reasonable window amounts. I managed to close the windows I wanted rather quickly usually. I think that (I'd have to actually take care and watch myself work) I tend to use it most for closing n out of m konsole windows, which is a huge pain with other methods, because the visual preview helps me a lot to distinguish them and to know which ones I want closed. Scripting this is close to impossible, using the taskbar is a huge pain, the best thing it offers is triggering the effect which just got the close functionality removed ;) > > Using it for closing n out of m windows, where m is the amount of all > > windows (and > n) is indeed debatable, but it's not the only usecase. > So you're using it for the (regular?) requirement to close all non-minimized > windows or those of the current VD or the current application? I use it often to close n out of m windows of the same application, konsole is probably the best example, followed by dolphin. > -> I'd rather consider a short script and a shortcut or pkill if I'd do > that more often. Let's take a (created, real world is probably less complex) example usecase: Say I have 6 workspaces and 8 konsole windows open across them, all of them having the same title (user@host) but given the past actions they have been used for they have a different backlog and are therefore visually quite easy to distinguish. There is no sane way to script that, and every shortcut that might call xkill has the issue that they are across different workspaces (or activities, for what it's worth). Using the shortcut to call present windows on a given application or clicking on the group in the taskbar which does the same and then just closeing the ones I don't need anymore is incredibly fast via this functionality. > > > therefore i recommend to drop the "got used to it" aspect > > Which, from an usability POV, is quite a critical mistake. > The recommendation pointed the reasoned unreasonability of this discussion, > i frankly dare to doubt that it contained a mistake (and hope you didn't > really mean that it was one) No, that was more pointed towards ignoring the "got used to it" argument. That the discussion doesn't do anything for this specific bug report is perfectly clear, as Martin and I pointed out already. But future decisions might benefit from it. Kind regards and good night Fuchs
Following the "destructiveness" path, the following options seem "destructive" as well: http://i.imgur.com/LRNZcNJ.jpg and therefore should be immediately removed. As well as middle-click-closing tabs in Dolphin. On GNU/Linux many graphical applications and environments facilitate the mbb for closing stuff -- making it a kind of standard. Enabling an option to allow mbb to close a Presented Window is simply following this very common and workflow-productive pattern. Following a common pattern in this scenario is very rational and logical as opposed to labelling such feature as "destructive behaviour" -- without having defended it with solid arguments (in this thread). Another pattern being not followed here is the high configurability of KDE, powerful options hidden under the bonnet -- this is what makes KDE different from GNOME and Unity. (We don't need another GNOME it is already there)
The best solution here would be to add back the option, only as an option, which will continue the philosophy of KDE being a highly configurable DE for power users. As an option this will have no implications for standard users, as they will not experience this behaviour by default. This setting as a non default option should satisfy both parties. This can be done in the next subrelease of KDE, in order to preserve the Freezing Policy.
> Let's take a (created, real world is probably less complex) example usecase: > Say I have 6 workspaces and 8 konsole windows open across them, all of them > having the same title (user@host) but given the past actions they have > been used for they have a different backlog and are therefore visually > quite easy to distinguish. There is no sane way to script that, and every > shortcut that might call xkill has the issue that they are across different > workspaces (or activities, for what it's worth). > > Using the shortcut to call present windows on a given application or > clicking on the group in the taskbar which does the same and then just > closeing the ones I don't need anymore is incredibly fast via this > functionality. but even better would be a QML based KWin script especially for this use case, right? The problem here is not that we removed the feature, but that we broke your workflow - a workflow for which Present Windows was never meant to be used. It's awesome that it is possible to do such personalized workflows, but nowadays we have a dedicated feature for custom workflows.
> As an option this will have no implications for standard users, as they will > not experience this behaviour by default. > > This setting as a non default option should satisfy both parties. erm it was exactly that. So no, sorry that doesn't make sense > > This can be done in the next subrelease of KDE, in order to preserve the > Freezing Policy. The next version will be based on Qt 5 and Qt Quick 2. I do hope that we will ship the QML based replacement I started to work on.
(In reply to comment #29) > > Let's take a (created, real world is probably less complex) example usecase: > > Say I have 6 workspaces and 8 konsole windows open across them, all of them > > having the same title (user@host) but given the past actions they have > > been used for they have a different backlog and are therefore visually > > quite easy to distinguish. There is no sane way to script that, and every > > shortcut that might call xkill has the issue that they are across different > > workspaces (or activities, for what it's worth). > > > > Using the shortcut to call present windows on a given application or > > clicking on the group in the taskbar which does the same and then just > > closeing the ones I don't need anymore is incredibly fast via this > > functionality. > but even better would be a QML based KWin script especially for this use > case, > right? Actually: no. It's neither better nor worse. I see myself as an end user there, and the end user rarely cares about the technology behind it unless it gives him a clear advantage (and even then he cares about that specific advantage, and not why it is there). So technically all kwin windows could be painted by little flying ponies inside the monitor and the user probably wouldn't care ;) > The problem here is not that we removed the feature, but that we broke your > workflow - a workflow for which Present Windows was never meant to be used. > It's > awesome that it is possible to do such personalized workflows, but nowadays > we > have a dedicated feature for custom workflows. Let's take the word "your" aside for now, I'll take care of that later. In general there are two problems: 1) You did break a workflow. 1 a) the problem is why you broke it. There is, in my opinion, no valid argument for it. That "destructive" is at least inconsistent has been shown by several users here by now, in addition to that it is in general invalid, imo. So the argument is imo "developers personal decision", which technically is perfectly fine, but then it should be argumented as that. 1 b) the problem is how you broke it. The timing was very bad, as there was no chance for users to react to it (also see next point) and no chance to revert it in time. The even worse issue: users who had it configured will get no indication at all that it got removed, so for them it just suddenly stops working after the update with no indication of what is wrong. This, from a usability perspective, is terrible. It will produce bug reports, also see last point in this reply. 2) Timing, reaction and feedback from users As mentioned in 1 b), the timing was quite bad. The biggest issue: It is great that you do work on a better solution. But given that KF5 is far far away, most users will have their workflow broken until then, with no alternative. There was, from what I can tell, no urgent reason to remove it now, so it could have been left there at least until the better solution is there. Because most users don't have an easy possibility to just patch kwin. And for distributions it is a problem because a) patching something that is not critical is a bad idea in the first place (just think of your beloved ubuntu bug reports) b) "my" patch works for me. It doesn't include translations, as an example. I just have hardcoded german strings. Distributions would have to take care of that as well. So basically what probably will happen is that as soon as 4.11 gets rolled out by more distributions, you'll get more bug reports (see 1 b)). This means additional work for you and triagers, and in addition to that: the atmosphere might become less friendly (we already had a CoC discussion, and it was like 5 people reporting it) as for the last point, the "your": I am not really affected. I use a source based distribution, it doesn't hurt at all to just have a local patch (which gentoo applies automatically) reverting that change. The main problem that I see is that probably most of your users do use binary packages provided by the distribution, they will suddenly use functionality without a visual indication of why, and I assume that most of them will not understand the reasons behind it (after finding this report) as well. So basically it will lead to 1) more bug reports 2) unhappy users 3) not-so-nice discussions And in my opinion this all could have been rather easily prevented by just leaving stuff in until there is a replacement. I also assume that this will take time which could be invested for better things, such as improving kwin (which, don't get me wrong, is an awesome window manager). And given that my point is probably clear by now I shall stop wasting your time, and leave this discussion for now. I hope that this situation can be avoided in the future, and I wish you all the best in the further development. Kind regards, Fuchs
> 1) You did break a workflow. -> https://xkcd.com/1172/ > 1 a) the problem is why you broke it. There is, in my opinion, no valid > argument for it. That "destructive" is at least inconsistent has been shown > by several users here by now, in addition to that it is in general invalid, > imo. So the argument is imo "developers personal decision", which > technically is perfectly fine, but then it should be argumented as that. I'm sorry but here we have to agree to disagree. I consider this as a valid reason. You don't. I will not convince you, you will not convince me. Please accept that I consider it as a valid reason and that I consider the need to protect the users in general as more important than the custom workflows of a few users. It's impossible to make everyone happy, we have to compromise. > 1 b) the problem is how you broke it. The timing was very bad, as there was > no chance for users to react to it (also see next point) and no chance to > revert it in time. The timing was not bad. The feature got removed in February while the decision to not do a 4.12 in workspaces was done in April/May. > The even worse issue: users who had it configured will > get no indication at all that it got removed, so for them it just suddenly > stops working after the update with no indication of what is wrong. This, > from a usability perspective, is terrible. It will produce bug reports, > also see last point in this reply. That was a risk we had to take. If we don't take such risks we are never able to remove features. But being able to remove features is important in a software development process. Please allow us to change our software. Thanks :-) > So basically it will lead to > 1) more bug reports > 2) unhappy users > 3) not-so-nice discussions This is completely up to the users. They can accept that there is the need and that while it is bad for them, it is a good change for the overall user base. They can also try to accept that we have more experience about such decisions than a user. And they can accept that we try to do what is best for the overall software. If they do accept this problem 2 and 3 are non existent. Problem 1 is not that much of an issue. So far the bug has been reported three times which is compared to distros destroying drivers a non-issue. > > And in my opinion this all could have been rather easily prevented by just > leaving stuff in until there is a replacement. see above - we sometimes have to remove features. Or do you think we should still carry tiling around? > > I also assume that this will take time which could be invested for better > things, such as improving kwin (which, don't get me wrong, is an awesome > window manager). again this is up to the user whether they want to discuss it. If they would accept our decision there would be no need for a discussion. Also note that we could just close the bug report for comments. Less than a minute work for me. Last remark from my side: it's my job as the maintainer to make decisions which some people do not agree to. That's the reason why we have maintainers. If everything could be done by everybody agreeing 100 % we wouldn't need maintainers. In the end the question is whether I as the maintainer think that it's the right decision and yes I think it is. Yes I knew people would complain and yes I nevertheless did it because I consider it as an important part of making our software more reliable and less destructive (note: all over the workspaces changes like these are done or changes are blocked because they would introduce unpredictable behavior).
*** Bug 324082 has been marked as a duplicate of this bug. ***
This is really a bad decision in my opinion. Those kind of decisions (taking the freedom from the user. Not even allowing the user to choose if he wants that feature.) were the reason I left GNOME and now it starts with KDE. What Martin does with his reasoning to remove that feature is to mark the users of KDE as stupid who don't know what they're doing. Comment #27 has it right: There's a lot of applications where clicking is "destructive". There's even options in KDE, as #27 pointed out. So Martins decision is not even coherent. As Martin is fixed on his opinion to dumbhandle the users I will revert back to 4.10 and stick with it as long as I can while looking for alternatives.
> taking the freedom from the user. Sorry but this is absolute bullshit. No freedom is taken away, all freedoms still hold. To iterate: Freedom 0: "The freedom to run the program, for any purpose" check Freedom 1: "The freedom to study how the program works, and change it so it does your computing as you wish (freedom 1)." check Freedom 2: "The freedom to redistribute copies so you can help your neighbor (freedom 2)" check Freedom 3: "The freedom to distribute copies of your modified versions to others (freedom 3)" check Which of the four freedoms should be violated? > Not even allowing the user to choose if he wants > that feature.) were the reason I left GNOME and now it starts with KDE. > What Martin does with his reasoning to remove that feature is to mark the > users of KDE as stupid who don't know what they're doing. Never ever come me with the "GNOME" or the "users are stupid" argument. Both is an absolute insult for the GNOME developers and in this case me as you infer that I consider users as stupid. Just as a note: I'm sick of the behavior of users behaving like this and I will now contact the community working group.
Top lel. He didn't insult GNOME. Not preferring the GNOME way of things is not an insult, it is just a preference. Btw he stated a fact on which we can all agree, you are 'dumb-handling' the users, which in turn this would be an insult as you are expecting your users to be not smart enough to be able to use that option Martin, hence you removed it.
But anyway, calling out each other on 'insulting' is just a childish joke. Let's stop this pussy talk, listen to users complaints, and if the number of unhappy users arises, then I think that would be a good sign to restore the feature.
Created attachment 81986 [details] Restore the options If you are on Gentoo simply place this patch in: /etc/portage/patches/kde-base/kwin And reinstall Kwin -- problem solved. (Note: I switched to Gentoo because of this bug)
@denysonique: Please keep in mind two things. The first is that our software is made by people who are working, for the most part, for free. So please refrain from insulting them. Second, please read our Code of Conduct [1]. In it we describe the way we want our KDE community to work. Using words such as "childish", "pussy" and "dumb-handling" are not polite, and not helpful. Collaboration is how we get things done. Everybody: Martin has explained his reasoning, and his roadmap for the future. Unless you have new information, please don't comment. 1. http://www.kde.org/code-of-conduct/
I dare to, because i was about to reply yesterday, but refrained, assuming that Martin would prefer to just ignore further useless "me too" comments. Now, what I wanted to explain is that the change was no way driven by the consideration "users are too dumb", nor that there's any "fixed mind" in play here. There is an alternative way to close windows from PW using the mouse (the close button). This alternative is enabled by default and has the advance of a visual indicator, keeping the learning/setup requirement low and allowing for an explicit action. It provides even more protection against accidental destructive action by being "dead" the very moment it appears, ie. it's more or less ensured that you actually recognized what you're about to click. This is actually a problem w/ the mouseclick closing, since the windows can re-shuffle unpredictably any time (whenever a window gots mapped or withdrawn programmatically), causing accidental actions. Iow: The assumption was and is that there is a superior solution to the then redundant "close on click" solution. This does not imply, either would be ideal for mass closing windows. Otoh, there's the argument of Fitts' law, which is technically obviously correct (the window is larger than the close button, "qed." - the button size can btw. be easily adjusted in the QML: 32px may very well be too tiny on High res displays) Bringing in Fitts' law however 1. postulates that closing windows from PW is an outstanding task (since hitting the close button is not harder than hitting any button in a toolbar) 2. requires an actual look at the function: T = a + b*log[2](1+ 2*D/W) "a" and "b" remain, what grows is D/W which is however inside a logarithm with static offset ("1"), iow. it does not grow very fast what means that the logarithm becomes irrelevant for large values of "a", which happens to incorporate the time to determine the click target. It has often been stated that "click-to-close" would be important for mass closing windows, but even with the most "robust" setup, closing windows invokes (nearly) unpredictable re-shuffling at some points, what means after each closing you first have to recognize whether the environment remained static, resp. if it's not, redetect your target. You may beg to differ, but the consideration was and is that PW was not suitable for mass closing this way (not saying it could not be made to by different adjustments, but it /is/ not) because of an overweight in "a" - thus the argument was disregarded, for not being an outstanding task. So much to what lead to removing the feature. No "being mean" or dumbness assumption included. --- Regarding why it will not be re-added: First off - it simply can't for KDE 4 (due to the freeze) This has been explained and nothing that could be just unilaterally changed. The timing was unfortunate, but not possibly to be foreseen. For KDE 5: Afaiu the actual demand is to make PW a more suitable tool for selective mass window closing. A different (filemanger-a-like) approach to this has been suggested. If you have reasonable (everything that focuses on the task and not the solution, ie. is not "it's not what i had!", is reasonable) concerns or addendums to that approach - i recommend to come up with them early.
While at it: (In reply to comment #27) > Following the "destructiveness" path, the following options seem > "destructive" as well: http://i.imgur.com/LRNZcNJ.jpg and therefore should be immediately removed. This had been added by a mass copy-over of contextmenu actions. I do not think anybody ever wondered whether or not this could be a reasonable action here. > On GNU/Linux many graphical applications and environments facilitate the mbb > for closing stuff -- making it a kind of standard. Since that is also a current topic on the GNOME front: No. This is simply wrong. ESPECIALLY on GNU/Linux, ie. "X11" The default and de facto standard behavior on X11 has for thirty years been pasting the primary selection (which GNOME now wants to change into generic actions, causing their user complaints ;-)
(In reply to comment #35) > > taking the freedom from the user. > Sorry but this is absolute bullshit. No freedom is taken away, all freedoms > still hold. To iterate: > Freedom 0: "The freedom to run the program, for any purpose" check > Freedom 1: "The freedom to study how the program works, and change it so it > does your computing as you wish (freedom 1)." check > Freedom 2: "The freedom to redistribute copies so you can help your neighbor > (freedom 2)" check > Freedom 3: "The freedom to distribute copies of your modified versions to > others (freedom 3)" check > > Which of the four freedoms should be violated? You know as well as I do that I was NOT referring to the freedoms associated with "free" software. The freedom you took is the freedom of choice. There's no option anymore to choose to close the window with middle-mouse-click. > > Not even allowing the user to choose if he wants > > that feature.) were the reason I left GNOME and now it starts with KDE. > > What Martin does with his reasoning to remove that feature is to mark the > > users of KDE as stupid who don't know what they're doing. > Never ever come me with the "GNOME" or the "users are stupid" argument. Both > is an absolute insult for the GNOME developers and in this case me as you > infer that I consider users as stupid. > > Just as a note: I'm sick of the behavior of users behaving like this and I > will now contact the community working group. Your argument is a strawman argument. You try to redirect the course of this discussion to a discussion about whether GNOME dumbhandles its users as well. Just as a note: I'm also sick of developers acting as if they were god and not listening to users and behaving like you.
For Arch Linux you can install customizepkg-patching from the AUR and place a file named "kdebase-workspace" in /etc/customizepkg.d/ like so: akurei@joel: ~ $ cat /etc/customizepkg.d/kdebase-workspace --- PKGBUILD 2013-08-28 00:05:20.000000000 +0200 +++ PKGBUILD.new 2013-08-28 16:44:36.293382731 +0200 @@ -28,7 +28,8 @@ backup=('usr/share/config/kdm/kdmrc') source=("http://download.kde.org/stable/${pkgver}/src/${_pkgname}-${pkgver}.tar.xz" 'kde.pam' 'kde-np.pam' 'kscreensaver.pam' 'kdm.service' 'kdm.logrotate' 'etc-scripts.patch' 'terminate-server.patch' 'kdm-xinitrd.patch' - 'plasma-desktop-dbus.patch') + 'plasma-desktop-dbus.patch' + 'http://files.akurei.me/patches/kwin-present-windows-close.patch') sha1sums=('3e877c9f82ad4b3d10c0752adbb50240707d632d' '660eae40a707d2711d8d7f32a93214865506b795' '6aeecc9e0e221f0515c6bf544f9a3c11cb6961fe' @@ -38,7 +39,8 @@ sha1sums=('3e877c9f82ad4b3d10c0752adbb50 'c079ebd157c836ba996190f0d2bcea1a7828d02c' 'ac7bc292c865bc1ab8c02e6341aa7aeaf1a3eeee' 'd509dac592bd8b310df27991b208c95b6d907514' - '57315ab3adf4d7eed9410c4494f0a63204122763') + '57315ab3adf4d7eed9410c4494f0a63204122763' + '3dbb34b44355b04282f3d186802245a6b5a553e6') prepare() { cd ${_pkgname}-${pkgver} @@ -52,6 +54,9 @@ prepare() { patch -p0 -i "${srcdir}"/terminate-server.patch # KDEBUG#321695 patch -p1 -i "${srcdir}"/plasma-desktop-dbus.patch + + # KDEBUG#321190 + patch -p1 -i "${srcdir}"/kwin-present-windows-close.patch } build() {
(In reply to comment #42) > The freedom you took is the freedom of choice. Then KDE is certainly a prison - and so is life - since there's a myriad of options you're never even offered. Is that what you want to say? Or are you just relabeling "prefabbed" as "freedom". Please focus on topic and stop pointless trolling. > You try to redirect the course of this discussion to a discussion about > whether GNOME dumbhandles its users as well. Reminder: you brought both, GNOME and dumbhandling, connotated, into this topic. Also there is nothing to discuss here - nothing can nor will happen in KDE4 and if you want to take any impact on the KDE5 solution to the complaints found in this bug, i recommend to alter your strategy. > Just as a note: I'm also sick of developers acting as if they were god and > not listening to users and behaving like you. Developers are in charge to take decisions that affect users - what might make the appear acting as gods to you, but that logics would also make your parents act as if they were gods when they forbid too much candy or sent you to bed early, no matter how much you cried. The claim of "not listening" is btw. wrong - it's more that these concerns arose "too late". The option was removed on February, 11th, the workspace moved into global feature freeze for KDE4 between May or June, 4.11 feature frozen June 5th and this bug opened June 15th. Fortunate or not, this doesn't say anything about the willingness to listen at all. -- Period.
(In reply to comment #44) > The claim of "not listening" is btw. wrong - it's more that these concerns > arose "too late". > The option was removed on February, 11th, the workspace moved into global > feature freeze for KDE4 between May or June, 4.11 feature frozen June 5th > and this bug opened June 15th. Sorry, but this is really unfair. As I told Martin and as it was acknowledged by him: timing here was bad on the kde/kwin side. The first sane possibility for users to test a new KDE release is the time the first Beta is released, because most major distributions simply don't provide sane packages before that. And if, then chances of things being broken or not compiling at all are there. This bug was reported almost straight after Beta 1 has been released, which is the first time users had the possibility to notice. As per http://mail.kde.org/pipermail/release-team/2013-June/007085.html the 4.11 Beta 1 tarballs have been made available for _packagers_ on June 13th, which is before end users get them. This bug was reported on June 15th. So aside from all valid arguments on your side: do not blame the users for things they are not to be blamed for. As I discussed with Martin, this definitely was a bad timing especially together with string freeze and the fact of this being an LTS, which was all aknowledged. Kind regards Christian
(In reply to comment #45) > Sorry, but this is really unfair. It would if i had tried to blame anyone for the timing, what i however did not. The point was about "developers not listening" what is wrong /because/ of the timing. > timing here was bad on the kde/kwin side. Timing is good or bad, but on no side. It's also obviously impossible to take any major decisions after the beta release - feature tracking has to happen during the development cycle (reading commit digests or whatever) - otherwise one misses one major release for sure. Price of point releases, unfortunately.
(In reply to comment #46) > (In reply to comment #45) > > Sorry, but this is really unfair. > It would if i had tried to blame anyone for the timing, what i however did > not. > The point was about "developers not listening" what is wrong /because/ of > the timing. Well, if you take the communication channels from your users away you obviously can not "not listen", because you couldn't listen either, you are completely "deaf" then. That seems like a somewhat odd argument to me. However, it doesn't really give the impression that you currently are listening to the discussion in here either. Arguments that have been refuted multiple times are brought again in more detail (which doesn't make them more right) and new side-discussions (timing) are brought into place. As the unfortunate situation is now here already the only thing remaining is "learning" from it, which, from my user point of view, would be: 1) Think even more before feature removals: do we break workflows? Do we have an alternative? Is it really needed? Is the gain (maintenance, ...) bigger than the issues it brings? Is it the right time to remove it? 2) Adjust the release process. Are the freezes at the right time? Is it possible to still make changes after a good amount of time in which users can give feedback? 3) Adjust communication: Inform users about changes and why they were needed (which needs 1) so the arguments are good and users understand them). Of course in an ideal world there would be an easy way for non-source-based distro users to get their feature back _until_ there is a proper replacement which has been communicated as such. But we know that this is not possible. Kind regards, Christian
(In reply to comment #47) > Well, if you take the communication channels from your users away you > obviously can not "not listen" Notice that I am ABSOLUTELY not available for ANY discussion about freezing kde-workspace. Please address kde-core-devel or somebody else if you feel like. > That seems like a somewhat odd argument to me. The oddity here is that you apparently don't see the difference between "you do not listen", "you can not listen" and "you listen but cannot react" I consider "you do not listen" a poor attempt to insult, where "you listen but cannot react" is a (n unfortunate) fact. > However, it doesn't really give the impression that you currently are > listening to the discussion in here either. Arguments that have been refuted > multiple times are brought again in more detail (which doesn't make them > more right) Had you read comment #40 even halfwise closely, you had noticed that it deals with the aggressive claim this option had been removed to "dumbhandle" users. I *wasted* some time to sum up the reasonable considerations that lead up to the decision, showing that "users are dumb" was not part in that. Leaving aside that "Arguments that have been refuted" should probably be "the argument that present windows is not suitable for mass closing" - the argument, though backed by sheer presence of bug #314393 has been "refused", yes - but certainly not "refuted". > and new side-discussions (timing) are brought into place. In you last (last!) comment your pointed out that you "told Martin and as it was acknowledged by him: timing here was bad" Since i'm not willing to believe that you forgot that in the meantime or are not even listening to yourself: Please stop trolling, it doesn't work. You won't get me out of temper, but I'll completely ignore every further post on this topic that contains *any* trolling. > As the unfortunate situation is now here already the only thing remaining You're repeating yourself... > 1) Think even more before feature removals: do we break workflows? As pointed out several times: the workflow you claim (mass closing) *has* been considered and it *has* been considered "void" for mentioned arguments and bug #314393 presence. > 2) Adjust the release process. What do you think how this works? Some "King of KDE" decides? FYI: there's been a lenghty discussion on this: http://lists.kde.org/?t=137331781500014&r=1&w=2 http://lists.kde.org/?t=137331818600036&r=1&w=2 Much fun reading. My personal opinion on this would btw. to scratch i18n as well as point releases - fetch KDE out of git whenever you feel like. > Are the freezes at the right time? > Is it possible to still make changes after a good amount of time in which > users can give feedback? By that logic, there'd never been a right time for the freeze. Major point releases are always feature frozen before the beta, that's the point of betas and point releases. Also it's quite silly to assume that some KDE SC4 -> KF5 transitions (ie. more global freezes) would stall so that you can abuse the Present windows effect as mass closing tool - it's absolutely irrelevant in that context. > 3) Adjust communication: Inform users about changes and why they were The command you're searching is "git log" - you can also subscribe to commit messages/digests and Review Requests and Martin keeps a blog. Do you expect a personal invitation? Or a singleton message because we knew that especialy you care about especially this change? Please. > Of course in an ideal world there would be an easy way for non-source-based > distro users to get their feature back Ask their distro to invoke a patch - and be willing to probably lead the same discussion there. > _until_ there is a proper replacement s/proper replacement/actually concepted solution/ You may not want to consider the close button a "proper replacement", but i will certainly not consider a change to pass PW some sort of "manage windows like files" a "replacement" either.
(In reply to comment #48) > (In reply to comment #47) > > > Well, if you take the communication channels from your users away you > > obviously can not "not listen" > > Notice that I am ABSOLUTELY not available for ANY discussion about freezing > kde-workspace. Please address kde-core-devel or somebody else if you feel > like. I don't need to discuss it with you if you don't want, no. But if you / your product is affected by it, then maybe this could be brought into discussion. > > That seems like a somewhat odd argument to me. > The oddity here is that you apparently don't see the difference between "you > do not listen", "you can not listen" and "you listen but cannot react" > I consider "you do not listen" a poor attempt to insult, where "you listen > but cannot react" is a (n unfortunate) fact. You can't react because of the fact that the timing was very unfortunate, an argument which I brought in very early and which was fully acknowledged (as "constructive" even). To quote you: << it's more that these concerns arose "too late" >> There was, as I mentioned with the dates provided, no chance to be "in time", and given that this (and other) arguments seem to be ignored (or simply seen as void) I'd still say "not listening". (Which is personal perception and far from an insult) > > However, it doesn't really give the impression that you currently are > > listening to the discussion in here either. Arguments that have been refuted > > multiple times are brought again in more detail (which doesn't make them > > more right) > > Had you read comment #40 even halfwise closely, I actually didn't, I read it closely instead. As with all the other comments. Please don't accuse me of not reading. > you had noticed that it > deals with the aggressive claim this option had been removed to "dumbhandle" > users. > I *wasted* some time to sum up the reasonable considerations that lead up to > the decision, showing that "users are dumb" was not part in that. If you go through my comments you'll notice that I wasn't one of the people accusing you of "dumbhandle" users. Also I think it's a bit sad that you see it as a waste of time, especially since I think that subject actually is done by now (well, I didn't bring it up in the first place, so I can only hope/assume it is done for the people who did) > > and new side-discussions (timing) are brought into place. > In you last (last!) comment your pointed out that you "told Martin and as it > was acknowledged by him: timing here was bad" The comment came up again (note that timing was in my very first bug report, which was a dupe) because it was brought up as an argument for the "not listening" part, where it is, in my opinion, simply sidetracking there. But point taken, I shall use a different example next time. > Since i'm not willing to believe that you forgot that in the meantime or are > not even listening to yourself: > Please stop trolling, it doesn't work. You won't get me out of temper, but > I'll completely ignore every further post on this topic that contains *any* > trolling. So while I invested quite a lot of time to bring up in detail what I think is bad and could be improved to avoid such cases, while I brought example usecases and facts (usability discussion above) other users insulted and pointed fingers, yet I am the one who is trolling? It's okay if we don't agree on this, we probably won't. It's okay if you don't want to spend more time on this, but accusing one side of trolling is not really a nice discussion style and in my opinion lacks some respect, especially in a discussion where people were already reminded to keep the code of conduct in mind. > > As the unfortunate situation is now here already the only thing remaining > You're repeating yourself... We all are, judging from the last few comments. This was meant to introduce the summary part, where I wanted to highlight the points which are, in my opinion, improvable. > > 1) Think even more before feature removals: do we break workflows? > As pointed out several times: the workflow you claim (mass closing) *has* > been considered and it *has* been considered "void" for mentioned arguments > and bug #314393 presence. If it has been considered void and if the replacement is that good: why is there a wishlist entry and development to cover this usecase? Again: if the alternative would have been here by the time the feature was removed, it would have been way less of an issue or none at all. However, the current situation is: the workflow is no longer available for a couple of months, but quite probably will be again later on. Which is odd at best. > > 2) Adjust the release process. > What do you think how this works? Some "King of KDE" decides? No, I actually follow the release team mailing list. > FYI: there's been a lenghty discussion on this: > http://lists.kde.org/?t=137331781500014&r=1&w=2 > http://lists.kde.org/?t=137331818600036&r=1&w=2 > > Much fun reading. > My personal opinion on this would btw. to scratch i18n as well as point > releases - fetch KDE out of git whenever you feel like. That might or might not work, yes. The issue here is that this currently is not the case, and in addition to the workspace long term release freeze, which was well known, this here lead to the mentioned situation: there is was no way for users to react with feedback in time. > [...] > > 3) Adjust communication: Inform users about changes and why they were > The command you're searching is "git log" - you can also subscribe to commit > messages/digests and Review Requests I follow quickgit loosely, the problem with subscribing to git commits is that there are _plenty_ of them all over workspaces and applications, so I'd say that it would be asked quite a lot of users to subscribe to all applications / parts that have functionality they use. Which is why I think that the release process needs to be adjusted: users who are interested in changes and testing use the betas. So it should be possible that their feedback leads to something, not only on bugs, but also on such changes (which could very well introduce bugs) > and Martin keeps a blog. Which didn't mention the removal. It did mention removals in the past, which I actually did comment on if I had something to add. > Do you expect a personal invitation? > Or a singleton message because we knew that especialy you care about > especially this change? > Please. No of course not. There is no need for exagerating or sarcasm. But given you seem to have had some sort of education in the field of usability (this is not an insult, rather me not knowing what exactly you studied in that field) I assume that you agree that a feature a user used in the past suddenly not working anymore, with no visual indication and not being mentioned in the release notes is hardly a great situation. Again, some feature removals have been communicated way better. > > Of course in an ideal world there would be an easy way for non-source-based > > distro users to get their feature back > Ask their distro to invoke a patch - and be willing to probably lead the > same discussion there. I mentioned earlier why I am not a huge fan of distributions patching upstream. Aside from it producing bug reports which can be a pain to handle (Because it only happens on distribution x) and the fact that it would also mean fiddling with translations it is, in my opinion, a broken concept in the first place. > > _until_ there is a proper replacement > s/proper replacement/actually concepted solution/ > You may not want to consider the close button a "proper replacement", but i > will certainly not consider a change to pass PW some sort of "manage windows > like files" a "replacement" either. https://bugs.kde.org/show_bug.cgi?id=321236 (Especially interesting since said itemviews and that functionality are mainly used in file management) Anyway, since we probably have to agree on disagreeing and the discussion style decreases a bit with accusations of trolling, I guess this shall be it for me. I have my patch, you have to handle the bug reports of users who don't. Mean, but works for me. I still hope that this discussion leads to improvements which will avoid such situations in the future. Kind regards Christian
On Thursday 29 August 2013 07:41:25 you wrote: > > > 1) Think even more before feature removals: do we break workflows? > > > > As pointed out several times: the workflow you claim (mass closing) *has* > > been considered and it *has* been considered "void" for mentioned > > arguments > > and bug #314393 presence. > > If it has been considered void and if the replacement is that good: why is > there a wishlist entry and development to cover this usecase? Again: if the > alternative would have been here by the time the feature was removed, it > would have been way less of an issue or none at all. However, the current > situation is: the workflow is no longer available for a couple of months, > but quite probably will be again later on. Which is odd at best. So I understand that you think the explicit button is not a suitable replacement. In my opinion it is. If it is not please report bugs about specific problems with the button. Keeping the mouse click action on the window is nothing else than a workaround to a possible unknown problem with the button. We should fix the problems and not treat the symptoms. > > Ask their distro to invoke a patch - and be willing to probably lead the > > same discussion there. > > I mentioned earlier why I am not a huge fan of distributions patching > upstream. Aside from it producing bug reports which can be a pain to handle > (Because it only happens on distribution x) and the fact that it would also > mean fiddling with translations it is, in my opinion, a broken concept in > the first place. For this case it's the only possible solution as we cannot reintroduce the feature due to the string and feature freeze. If a distro is not frozen they can still do so (might already be too late for Ubuntu 13.10). In general I agree.
(In reply to comment #50) > [...] > So I understand that you think the explicit button is not a suitable > replacement. In my opinion it is. If it is not please report bugs about > specific problems with the button. > > Keeping the mouse click action on the window is nothing else than a > workaround > to a possible unknown problem with the button. > > We should fix the problems and not treat the symptoms. Sure :) As just discussed: reference for those who are interested / have good ideas / want to try alternatives: https://bugs.kde.org/show_bug.cgi?id=324234 Kind regards, Christian
I don't think I've seen this mentioned before: there is a major piece of KDE software which by default uses middle-clicks on tabs to close them: Dolphin. This is very useful. (I really hope someone reading this doesn't try to convince the Dolphin devs to rip that out now. :/ ) I have also set up my Firefox profile to have no Close buttons on tabs, and to use middle-click to close them. This is a double-win: 1. I don't waste limited screen space on having a Close button on every tab. That adds up when you have 15 tabs on-screen, and saves that space for the tab titles. This is even more important on small systems with small screens. 2. I don't ever have to worry about accidentally closing a tab by clicking on a Close button instead of activating the adjacent tab. I'm never going to accidentally click my mouse wheel button instead of the left button, but it's easy to accidentally click a few pixels off-target. By the way, I have always disabled the middle-click-paste feature in Firefox. I can't tell you how many times I missed middle-clicking a link by a pixel or two and ended up with Firefox trying to load whatever happened to be in the clipboard as a URL. Besides, Firefox and Chrome have "Paste & Go" options in the address bar context menus now, and such an option could easily be added to the tab menus. So the conclusion is clear to me: having the option to use the middle button to close windows (or any kind of object) actually *reduces* the likelihood of accidental "destruction." It actually results in a *safer* and *friendlier* UI. Since the primary argument given for removing this feature was to prevent accidental destruction, it's clear to me that removing it was actually counter-productive toward that goal. And since the patch to restore the feature is 22 lines of code, 15 of which is XML in UI files, it's clear that the real reason for removing it was one person's personal preference. Otherwise, the needs to "make software that everybody can use" and prevent accidental "destruction" would require that most of all of KDE SC's and Plasma Workspaces' configurability be removed in favor of single-path workflows. Either the principle is valid and should be applied to everything, or it's not valid and doesn't justify anything. P.S. I know this bug has been idle for a while. I'm sorry I just discovered it. The reason I am posting this is because I haven't seen anyone mention Dolphin's use of middle-click to close tabs, and I think it's a very important point. No hard feelings are intended--we're all supposed to be on the same side here, working toward the best Free Software for the good of mankind, with each of us acting in the roles we're capable of. Disagreements are inevitable. I just don't think the arguments given for removing this feature are logical at all, because they're not consistent with the rest of KDE or much other software. Since it was never a default, it does absolutely no harm to leave it in, and it is very beneficial to many.
> I don't think I've seen this mentioned before maybe you had better read the bug before? See comment #23 & #26 Pro tip: press ctrl+f and enter "dolp" in your browser... > This is very useful It's primary a feature of KTabBar, interoduced there to clone the firefox behavior. > I have also set up my Firefox profile major problem here: kwin is neither a browser, nor are we talking about tabbars. And the tabbar behavior is questionable as pointed out before. > By the way, I have always disabled the middle-click-paste feature in Firefox. Same problem again: this is not firefox. But I grant that the firefox eventhandling is not always entirely sane. Different actions for the same input on a pixel margin (this also includes adding a tab) is stupid. Personally i'd keep the link middleclick and paste only in the tabbar (thus replacing tab contents or opening a new tab with the valid url and if the selection does not contain a url, just open a new tab) - but that's completely off topic here. > So the conclusion is clear to me The conclusion out of what? You talked about weaknesses in the firefox moubutton handling, out of where do you draw a conclusion for anything but firefox here?? > having the option to use the middle button to close windows (or any kind of object) You want to redefine the standard middleclick behavior on X11, fine. But that first has to happen and given the gnome approach in that directon, you may expect MAJOR resistance. Much fun, call back when middle clicking is supposed to close things. > And since the patch to restore the feature is 22 lines of code, 15 of > which is XML in UI files, it's clear that the real reason for removing You wish to read an actions reason out of the amount of changed LOC? Seriously?
*** Bug 325000 has been marked as a duplicate of this bug. ***
From reading the discussion above briefly, i understand that i cannot convince you to change your mind about this bug and re-add it. However i'm still unclear about the motivation to remove it. You said it's destructive and that's the reason to remove it (with which i disagree btw). My question is: What made you conclude that? Did you get any signs from community that it's making them close their windows randomly? I mean, of course you can close many windows "acciedentaly" this way, but for sure you cannod do that for anything important as that'd make the window itself pop up some "Are you sure?" message. And clicking "Yes" on that is intentional to say at least, especially since you can't do that trough window presentation effect. I'm really interested in how many are affected possitively and how many negatively by this removal, statistically. Not sure if this is even possible to gather though. I'd also like to propose an alternative solution here: can you please add some kind of "legacy window presentation" to KDE effects repository, so that i can just click "add more effects" and download it? I'd be veeeeery handy. Cheers, Tom
(In reply to comment #55) > convince you to change your mind about this bug and re-add it. We could not even if we wanted. Workspace is feature frozen until PW/2, aka "KDE 5" > still unclear about the motivation to remove it. see comment #40 > cannod do that for anything important as that'd make the window itself pop > up some "Are you sure?" message. Have an xterm, have it run a looong and expensive job in foreground, close it 5 days after the job started and 5 seconds before the job would be done and write results. iow: "we can be risky because the client will deal with that" might hold in particular, but is a wrong assumption in general. > I'd also like to propose an alternative solution here: can you please add > some kind of "legacy window presentation" > Workspace is feature frozen until PW/2, aka "KDE 5" You can have 3rd party effect plugins, but got to compile them yourself (you could just pick kwin sources, revert the commit and compile/install the result. > i can just click "add more effects" and download it? No, that's only for scripted effects. Scripting PW is a target for PW/2 but not possible with current scripting infrastructure. For now it requires c++
(In reply to comment #56) >Have an xterm, have it run a looong and expensive job in foreground, close it 5 days after the job started and 5 seconds before the job would be done and write results. Such jobs should be run in Screen to prevent any kind of accidental closing or in the event of Xorg crashing. #40 Still does not explain exactly why it was completely removed. The setting being a nondefault option was already a justification for the option to be there. UI development is an Art not a Science.
> You can have 3rd party effect plugins, but got to compile them yourself (you > could just pick kwin sources, revert the commit and compile/install the > result. Well, i hope that besides compiling it myself i can also download some precompiled effect, copy to some effects folder and have it working "out of the box". If that's the case, can you prepare such thing? The thing is that of course, i could do this myself, but for me it might take days to dive into kwin sources, extract the required files and finally put them together into something that works.
(In reply to comment #58) > > You can have 3rd party effect plugins, but got to compile them yourself (you > > could just pick kwin sources, revert the commit and compile/install the > > result. > Well, i hope that besides compiling it myself i can also download some > precompiled effect, copy to some effects folder and have it working "out of > the box". If that's the case, can you prepare such thing? Probably hardly, as it has to be done per distribution and architecture. It _could_ be done by distribution packagers for their packages, for that you'd have to open a bug report there. >The thing is that > of course, i could do this myself, but for me it might take days to dive > into kwin sources, extract the required files and finally put them together > into something that works. Nah, it is a matter of a few seconds if you know how to compile things. Basically you can download the diff that is linked in the review requests and apply it with patch -R, or take the attachment to this bug report, which is basically a prepared patch (a reverted diff). The main issue is: depending on what distribution you are using, you should not just compile and install kwin, but rather build a proper package (rpm, deb, whatever). Most common distributions do have simple manuals for that, but without you telling us which distribution that is, it is a bit hard to give proper directions. Kind regards, Christian
> Well, i hope that besides compiling it myself i can also download some > precompiled effect, copy to some effects folder and have it working "out of > the box". If that's the case, can you prepare such thing? No we cannot. We only provide source and it's the task of the distributions to package it and provide it as binary. The problem is that there might be differences between distros (meaning my built binary might not work on your system) and architectures (I only have amd64 while you might have i386)
Is there any workaround besides this patch/compile mess meanwhile? Maybe a KDE plugin? It is sad that this feature is gone. KDE's appeal to me is that it is highly customizable. It is sad that KDE now seems to drop its strongpoint, if non-default options are dropped for such silly reasons.
First of all, I'm a big fan of KWin. It's amazing what you guys have achieved since I started using KDE 4.1. I realize that it's too late to have this back in KDE4 without compiling yourself, but I wanted to raise another point to support this features inclusion in the next release (PW2). Aside from Fitt's law, another thing which makes middle clicking to close a window much easier than hitting the close button is that you don't have to look at your mouse. When hovering over a window during PW, it becomes raised and highlighted. This gives you the assurance (without moving or looking at your mouse) that if you middle click the current window will be closed. Even if the current highlighted window is not the one you want to close, you can estimate the motion required to go to the desired window and perform a twitch mouse movement to the window you want to close. This is much faster and has less cognitive load than moving to a small close button while looking at your mouse. While this may seem like a small point, this aspect really helps someone like me who interacts with their computer very fast. All other points have been argued before me, so I won't go into them. I really hope this gets added back as a non-default option. Thanks again for your great work.
*** Bug 341095 has been marked as a duplicate of this bug. ***
I'm aware that this bug is very old and that it is incredibly unlikely to be changed in KDE4 especially since KF5 (or whatever) is much closer to be the default option but I just wanted to comment on the disappointment that this thread gave me. "the action is seen as destructive" is a disappointing and flawed reason for removal of a closing feature because of course it is, that is the whole point. The feature is to make it easier to close something, that's exactly why I want it. -------------- @Fuchs made many good points about not only the validity of the feature but also the fact that removing it does not benefit anyone without the existence of a replacement. -------------- @denysonique with comment #27 made a great point that the ability to close an application via middle click on the titlebar is essentially the same destructiveness that having it in Present Windows provides. It doesn't make sense when one "destructive" feature is ok but another one isn't. It has been over 2 years, why is the destructive titlebar closing feature still available? (I don't agree with everything this person said, just this one point is what I am referencing) I mean what if I choose to make the middle click on titlebar be a close feature but I also have middle click on the maximize button to vertical maximize and then I miss the maximize button and thus close the window. = usability problem. If I choose to middle click close a window in Present Windows, the result would be only benefit. It is not possible to accidentally middle click a window in Present Windows because by default it does nothing so users who havent chosen it aren't affected and I am pretty sure it is safe to say that probably no one has confused their left mouse button with the scroll wheel button. I mean there are a lot of users who aren't even aware that the scroll wheel is also a button. --------------- @priomsrb@gmail.com in comment #62 made a great point that the window highlight of Present Windows guarantees that the concept of the windows moving creating usability problems is flawed and since the user doesn't even have to know where the mouse is proves that it is in fact a benefit to usability. I actually use the Grid layout for Present Windows which minimizes the window movements as well thus negating the movement as a valid argument even further. --------------- @Martin your reason is fundamentally flawed and is overall a bad decision. The idea that it is destructive is exactly the reason why we want this feature, to improve the speed of which to close windows. The fact that this feature would only be used by people who chose to use it removes your argument of it being destructive to users who weren't expecting it because by default they are not affected by it in any way so they should not be considered. @Martin if you were to have said "I don't like this feature and I do not want to be the person to be attached to this feature in KWin. I chose to remove it because I do not agree with it being there." This would be a fine response and an ideal response would be to have additionally said "but if someone else were to write it and submit it to the package then by all means.". This validates your desire to remove it but still allows it to be reinstated had someone chosen to do so, rather than a stubborn "wontfix". If this feature created some kind of bug in Present Windows or something else then by all means, remove it but through this thread and the other threads, there was not a single mention of actual breakage created by this. Essentially, you don't like it so you decided that your opinion inherently trumps all other opinions. One of your points was the "X feature" of middle click pasting and I can tell you that I absolutely despise that "feature". In all web browsers you can middle click a link to open it in a new tab, I do this almost always. Sometimes, I screw up when I click and being slightly off the link forcing me to go to a url and creating a usability problem. I can not stand that bug disguised as a feature but I know some people like it and instead of complaining I just disable it. In comment #32, @Martin you said that "I consider the need to protect the users". That statement is insulting or at the very least arrogant that you consider it your duty to protect users from themselves. The only users who were using this feature were people who chose to do so and thus you are essentially saying that you are "protecting people from their own preferences". The result of this debate is quite disappointing and I hope at some point that the feature is reinstated by anyone in any way. I don't care if it is done via KWin Script, Plugin or a KDE provided option . . . @Fuchs is absolutely correct, I want this feature and I don't care how it is done to accomplish it. --------------- I think KWin is easily the best Window Manager, in not just Linux but, in computing universally. One of the reasons is the vast control I am provided by KWin in so many ways especially Window Rules and I respect all the work that Martin as done as well as the other developers. KWin is genuinely amazing and I love it but the response to negative feedback here is disappointing. > "They can accept that there is the need and that while it is bad for them, it is a good change for the overall user base. They can also try to accept that we have more experience about such decisions than a user. And they can accept that we try to do what is best for the overall software." Essentially that just says "they can accept it or move on". The biggest thing that disappoints me though is you never explained why it was bad for the "overall user base". The only people who were affected by it were people who wanted it and so the opinion of the overall user base is actually ignored for the opinion of one person, the developer.
from https://bugs.kde.org/show_bug.cgi?id=348352 >...in 5.4 you can pick between New Instance and Close for middle-click in the config dialog. Meanwhile, some developers return "destructive" features! Praise them for the opportunity to choose from! P.S.: "End-User Focus to ensure our work is useful to all people." [1] [1] https://manifesto.kde.org/
hey @imraro: if you want us to change it please don't add snarky comments like comment #65. That just helps to make me upset and ignore the issue even more.
Excuse me, I did not want to offend anyone. I really appreciate your work. Kwin is best of the best of the best (c) But I can't understand destructiveness of hidden and disabled by default feature. Please give us ability to shoot oneself in the foot.
Some random thoughts on the feature request: ---------- If one was to add this for the (apparent) main purpose of (quick, mass) window closing, the feature should be desigend towards this, what requires some major changes/additions in the present windows effect. a) no (close) input handling while windows are being animated and until ~1s afterwards (to allow the user recognizing the change and for re-orientation) b) ~10s delay for re-layout after a window is closed (so you do not have to re-scan the grid each time) c) allow interaction with (notably) modal dialogs after close attempts ("forgot to save?") d) bonus points if the feature is modal (you click a button and then stay in "close" mode) and indicating (eg. hovered windows shrink and are tinted red or something like that) (c) is the major issue, yet affects the close button (should probably not be there either...) as well. It will require to - reset the (visual) geometry of the to-be-closed window and its modal transient - move them on top of the stack (*NOT* just elevate them visually, they need to be above the effects input window) - "watch" them, for three things may happen in turn 1. dialog and window close. 2. dialog closes, but window remains 3. dialog closes, window remains, but another modal dialog one opens (eg. a save dialog) For (1) and (2) you want to "return" to the normal processing, but you've to distinguish 2 & 3, ie. after the first dialog closes, wait either a second or until the main window closes. If a new dialog spawns for the main window, stay where you are, otherwise return to the normal processing and in case a second dialog opens, you just start the entire process over (as if it was the first modal dialog for the to-be-closed window) /my2¢
(In reply to Thomas Lübking from comment #68) > If one was to add this for the (apparent) main purpose of (quick, mass) > window closing, the feature should be desigend towards this, what requires > some major changes/additions in the present windows effect. fsvo major, see below. > a) no (close) input handling while windows are being animated and until ~1s > afterwards (to allow the user recognizing the change and for re-orientation) > b) ~10s delay for re-layout after a window is closed (so you do not have to > re-scan the grid each time) These two are trivial to solve by adding it as a mode instead, in which the action on click is "close". The mode could be visually highlighted (e.g. red tint, red borders etc.) and could be, to make everybody happy, both toggle-able with clicking a button or via holding a modifier key. This way you could implement a similar mode for other actions, such as "pull to current desktop". Then you could mass-manage windows easily and disable effects / recalculations / movements and the likes while that mode is active. I can do mockups if needed, but I think it should be clear. Short: - have modes that you can toggle via mouse or keyboard - in these a click does a specific action, e.g. close - While in these, re-ordering windows, moving them and the likes is disabled > c) allow interaction with (notably) modal dialogs after close attempts > ("forgot to save?") > d) bonus points if the feature is modal (you click a button and then stay in > "close" mode) and indicating (eg. hovered windows shrink and are tinted red > or something like that) Note that other forms of closing windows (plus the feature mentioned in this request, which got removed) did not offer any of that. While I agree that it would be great, I'd consider both a bonus and not a blocker. > /my2¢ As a minor sidenote: while the thoughts and solutions you propose are very good, note that this feature was happily used without any of that. I've yet to come across a user who accidentally closed his window like that, on the other side we already have a couple of users who used the feature as is ... so maybe this could be avoided in the future by either not removing features, or allowing users to voice opinions on it before it is "definite due to translations". :p Kind regards, Christian
(In reply to Martin Gräßlin from comment #66) > hey @imraro: if you want us to change it please don't add snarky comments > like comment #65. That just helps to make me upset and ignore the issue even > more. My comments were not snarky and in fact were in-depth heavily consider comments that both address your previous comments and several other comments in this thread. Please, respond to my original post. ---------- (In reply to Thomas Lübking from comment #68) I'd just like to say that the ideas/features you are suggesting would be really cool and would be great to have but they are not a necessity for the fundamental feature requested by this bug report. I simply want the ability to middle click the windows, if I have to move my mouse because the window adjustments happen then that is totally fine with me. I would like to have what you suggested but by no means are they required to make this initial feature useful. ----- (In reply to Fuchs from comment #69) > Note that other forms of closing windows (plus the feature mentioned in this request, which got removed) did not offer any of that. While I agree that it would be great, I'd consider both a bonus and not a blocker. > As a minor sidenote: while the thoughts and solutions you propose are very good, note that this feature was happily used without any of that. I've yet to come across a user who accidentally closed his window like that, on the other side we already have a couple of users who used the feature as is ... so maybe this could be avoided in the future by either not removing features, or allowing users to voice opinions on it before it is "definite due to translations". :p I agree with this completely, while those would be cool they are not reasons to stop this feature from existing. The point of the accidental closing being a non-issue is also correct because I too have never heard of a single person experiencing this issue, especially considering the feature isn't default in the first place it in guarantees that this is a non-issue. ------- There is absolutely no reason for this feature to have been removed and considering it has been multiple years and Martin has never provided a single valid reason proves the point of "Developers don't always know what's best for the user". This divide for who knows best is the point of having a dialogue for discussions and is why developers and users should listen to each other. in this case, the debate is easily on the side of the users.
(In reply to Michael Tunnell from comment #64) I'll give you a custom reply, despite this was largely a "+1" post. > @Fuchs made many good points about not only the validity of the feature but > also the fact that removing it does not benefit anyone without the existence > of a replacement. Wrong. There /is/ a "replacement" (dedicated close button, iirc enabled by default) Yes, it's not the middle button and you've to click a specific item - thus "replacement", not "the same" The patch that removed the feature also explicitly states the replacement. > @denysonique with comment #27 made a great point that the ability to close > an application via middle click on the titlebar is essentially the same > destructiveness that having it in Present Windows provides. Wrong. In the normal context, windows don't suddenly juggle around below your mouse (thus my list of requirements - I didn't just make that up) > I mean what if I choose to make the middle click on titlebar be a close > feature but I also have middle click on the maximize button to vertical > maximize and then I miss the maximize button and thus close the window. = > usability problem. Void. If you cannot control where you click, you've more severe and general problems. In this particular example, increase the size of the maximization button (the hover contrast of at least the breeze decoration should be sufficient in any case to feedback whether you hovered the button or not) > It is not possible to accidentally middle click a window in Present Windows Void. The problem is not accidentally clicking, but a) accidentally clicking the wrong item (as they may alter positions on events out of your control) b) no contextual info about the (as we agree) destructive nature of your action (you could have forgotton the configuration or accidentally set it - and that *does* actually happen) (Sidenote: I've actually accidentally clicked the middle button because a usb-reconnect of the mouse which reset custom button mapping, I prefer the MMB on the thumb) > @priomsrb@gmail.com in comment #62 made a great point that the window > highlight of Present Windows guarantees that the concept of the windows > moving creating usability problems is flawed Wrong. You can maybe react in 500ms (though a common value is 1s), but the system operates in terms of nanoseconds and the translations take << 500ms. You send your finger the "now click" signal and at that moment the windows are re-layouted, you have no chance. (I'll re-state that I didn't just mention some random points to scare people off) > @Martin your reason is fundamentally flawed and is overall a bad decision. > The idea that it is destructive is exactly the reason why we want this > feature The problem is *not* that "it is destructive" by itself (despite this may have gotten lost in this thread over the discussion whether closing is destructive at all) but that there're requirements to destructive actions that the "close-by-middleclick" feature (unlike the close button) didn't meet. > "I chose to remove it because I do not agree with it being there." >[...] > "but if someone else were to write it and submit it to the package then by all > means." The "not interested, but patches welcome" pattern entirely doesn't fit here. Just reverting the patch that removed it is no actual technical challenge and "[...] I do not agree with it being there [...] but if someone else were to [...] it [...] then by all means" is self-contradicting. > Essentially, you don't like it so you decided that your opinion inherently > trumps all other opinions. As long as Martin is the maintainer of KWin, that's his privilege. Yes. If I would think that he abuses it, I'd btw. state that. Explicitly. Since he just replaced a blind feature with an explicit one (saving even one input event, ie. you can use the MMB elsewise) I have however no reason for this. > One of your points was the "X feature" of middle click pasting and I can > tell you that I absolutely despise that "feature". Your personal feelings about this X11 feature are, frankly, irrelevant - it exists and needs to be taken into consideration. ---- Rest went ad hominem, just one thing: > In comment #32, @Martin you said that "I consider the need to protect the > users". That statement is insulting or at the very least arrogant that you > consider it your duty to protect users from themselves. Please do not take quotes out of context to then imply a different meaning into them. Martin said: "[... that] I consider the need to protect the users in general as more important than the custom workflows of a few users. It's impossible to make everyone happy, we have to compromise." He notably did *not* say "to protect users from themselves", as you insinuated. The feature had no indicating feedback (the HIG team would btw. crucify us. Thomas P. would not be happy. Entirely not happy. ;-) and was not rebust against accidents. It allowed _the_GUI_ to "trick" the user, thus was replaced by one (possible alternative) without those defects.
To move forward I suggest that people interested in this feature try to take it to a higher level. KDE doesn't have a body like a "tech board" which can override maintainer decisions, but we have some other places where you can raise your concerns. Feel free to raise this issue with the Visual Design Group [1] - if they tell me this is an absolutely needed feature and the removal was wrong, I might be willing to reconsider. If you think that here is a severe conflict between users and developers I urge you to contact the Community Working Group [2] and inform them about this issue, so that it can be resolved. Otherwise I think we are moving in circles and there are no new arguments which we developers can bring up, neither are there any the users can bring up. Given that I think this bug report is very frustrating for all of us and we should leave it here and stop the discussion. [1] https://forum.kde.org/viewforum.php?f=285 [2] https://ev.kde.org/workinggroups/cwg.php
(In reply to Martin Gräßlin from comment #72) > To move forward I suggest that people interested in this feature try to take > it to a higher level. KDE doesn't have a body like a "tech board" which can > override maintainer decisions, but we have some other places where you can > raise your concerns. > > Feel free to raise this issue with the Visual Design Group [1] - if they > tell me this is an absolutely needed feature and the removal was wrong, I > might be willing to reconsider. This issue has over 70 comments with people begging for this feature to come back, why do we, as users, need to contact the VDG? So we, as users, wait another year for the issue to be solved? I understand the destructive part but c'mon, if users want that why don't giving them that? It's not a new feature it's something that existed before. It's something that is not default, the users has to go that those settings and specifically select "Kill windows with right mouse key". I honestly don't know how to be productive like I was 2 years ago with KDE. 2 years ago: - I want to close unnecessary windows: mouse to the left upper corner (showing all windows), right clicking every one that I don't need it: 1 seconds/window. - I hear my laptop fan going crazy: mouse to the right bottom corner to minimize all windows (called show desktop) quickly seeing my conky stats (net/mem/cpu): 0.1 seconds. present: - I want to close unnecessary windows: mouse to the left upper corner (showing all windows), going with the mouse on every X of every windows: 2 seconds/window. - I hear my laptop fan going crazy: double clicking on every window that is not gray on the task bar so I can minimize it, and that restore the one I was using it: 0.5 second / windows open. I never cared about effects nor fancy things but this is something that I need and use for productivity. To tehomail@gmail.com, if you decide to go with [1] or [2] I'll back you up. Either way since KDE is open-source anyone can add this feature.
This bug report has 70 comments and 13 subscribed users. We have millions of users. Please understand that I'm not impressed by those numbers.
Hi all, let me try to give a bit of an external / new view to this. Going through the various points criticized: On whether this debate is constructive: it's interesting to see that the comments containing recommendations, possible solutions ore the likes are mostly ignored, while the comments with a high possibility of conflicts are almost scientifically analyzed, stripped down and replied to in a similar manner. Of course this isn't going to yield results. As for the tone: communication is a bi or multi directional thing, it doesn't really work to criticize the tone while replying to (more or less valid) arguments directly with "wrong" or "void", especially if your arguments are flawed, too (more on that in a bit). And to be honest: none of us are experts, probably all of our arguments have some flaws. Now fortunately on to the more technical part: If your arguments are based on a UX point of view, please keep in mind that a very basic thing you learn in interface design is how much time specific actions take. Pointing (as in: detail aim) with a mouse is among the most time consuming thing, so making that mandatory for a repetitive action is simply a less than ideal idea, UX wise. The solution provided in comment 69 would solve this (depending on how the toggle switch is implemented), but so far it seems to be ignored. If your arguments are based on (accidental) destructiveness: note that the current solution is even worse. The (optional) buttons you mentioned have two flaws: first of all, they are not always visible. So chances are, despite apparent efforts to avoid this, that they pop up under your mouse right when you click. That is accidentally (and non reversibly) closing a window. The second flaw: They (KDE 4.12.*) provide a rather bad contrast, if you have a default-gray-ish colored window below them, chances are you don't even see that there is a button. So again: chances are you click there by mistake, which is exactly what you criticize. If your arguments are based on a program not acting as you expect it to: The action used to be configurable and as far as I remember the default did not include closing it. So if a mouse button of your choice closes a window, then it's only because you configured it to. Note that a lot of other applications, including KDE ones, do not offer this configuration and close tabs or the likes on middle click by default (and without a choice, sometimes). The "no visual indicator" argument is rather valid, but note that a couple of other (destructive) actions, such as the above mentioned tab middle click or the double-click close on window icons, does not have such an indicator either. The UX point of view there is consistency: other applications behave the same, thus users already know what a certain action does. Last but not least: using numbers is, on both sides, silly and hardly constructive. If a critical bug (e.g. losing data) happens to just 5 users, it would still be critical. Giving numbers is not going to help, saying that one is not impressed by numbers looks a bit like lack of respect and won't help either. Involving the VDG could be a good thing, as they probably have a bit more weight than just unknown users saying "but UX wise, $x is ...". They might also be able to propose a replacement that has less flaws and would make most people happy. As said, I think a couple of good proposals have been made in the roughly 70 past comments, but unfortunately they seemed to have gotten a bit lost in all the bickering and fighting. My two cents, I hope they help.
(In reply to Markus P. Leiser from comment #75) > So chances are, despite apparent efforts to avoid this, that they pop up under your mouse > right when you click. Wrong. If it shows up under the mouse it's disarmed for 300ms (tight, but considered sufficient - you may try for yourself whether you can use it in a way you's consider accidental) > They (KDE 4.12.*) provide a rather bad contrast, I'll make a personal and bold statement, which is however no secret opinion: The air theme was a general usability disaster, yes. Don't use it. :-(
(In reply to Thomas Lübking from comment #76) > (In reply to Markus P. Leiser from comment #75) > > So chances are, despite apparent efforts to avoid this, that they pop up under your mouse > > right when you click. > Wrong. Again, I don't think that replying "wrong" to a comment right away is going to be useful, especially as you criticize the tone. > If it shows up under the mouse it's disarmed for 300ms (tight, but > considered sufficient - yes, as I wrote (you even cited): "despite apparent efforts to avoid this" > you may try for yourself whether you can use it in a > way you's consider accidental) Yes, I managed to. Aided by the mentioned missing contrast, this is indeed not too unlikely to happen. At least as likely as using the "wrong" mouse button I would say. > > They (KDE 4.12.*) provide a rather bad contrast, > I'll make a personal and bold statement, which is however no secret opinion: > The air theme was a general usability disaster, yes. Don't use it. :-( It is the default. The contrast has, from what I have seen in other kwin reports, been criticized in the past, too. So I wonder why that, if the argumentation is really based on "not clicking the wrong element by accident", this has not been fixed. Anyway, there is a proposed solution which would address the visibility issues, the usability issues and the use case of managing multiple windows quickly. I guess if this is supposed to be solution oriented, one could maybe try to focus on improving, discussing or implementing (I am not a programmer) this feature instead of accusing each other of being wrong.
The point of Air theme is mood nowadays. 4.11 is going to EOL this month - there won't be any changes to it any more. On Plasma 5 the default is Breeze and the visual design group is the place to discuss any changes for it. For us as the KWin project: we don't care about how it looks like, style comes from other areas not part of KWin. Anyway: I don't think we are moving any way here. I have asked the VDG for a redesign of Present Windows quite some time ago. Let's move that project forward, there won't be significant changes to the current Present Windows codebase anyway.
I understand that KDE 4 is now feature frozen, so it can't be readded there. And from comment #65 I understand that it has been re added to Plasma 5. Given that, I think that if any of you guys still use KDE 4 and you miss this feature a lot, then I suggest to either build kwin with patch from comment #38 (easy if you use gentoo, like me) or perhaps you can try asking your distribution maintainers to apply this patch to their builds.
I haven't replied in a while so I am going to reply in chronilogical order. ------ @Thomas Lübking > There /is/ a "replacement" (dedicated close button, iirc enabled by default) This is ~5-10% the size of the window box and therefore requires excessive movement for clicking, so yes a replacement which is an inferior replacement, thus regression. There should be both, not either or . . . both. > In the normal context, windows don't suddenly juggle around below your mouse (thus my list of requirements - I didn't just make that up) You are the only person who considers this a problem. I don't mind that the windows move around, they already move around and considering the tiny size of the close button this issue should be a reason for you to want this middle-click feature rather than defending the removal. The movement of the windows is a huge pain right now with the tiny close buttons but with the middle click on the windows this movement is no longer an issue as it would be so much easier to accomplish the goal regardless of their movement. >> have middle click on the maximize button to vertical maximize and then I miss the maximize button and thus close the window. = usability problem. > If you cannot control where you click, you've more severe and general problems. The point is that the feature is selectable by the user and that would have potential conflicts with another feature. The feature in question of Middle Click Close in Present Windows (MCCiPW) has no conflict with any other feature so because of this, the titlebar closing option is more destructive than the MCCiPW. I am not saying that the titlebar portion should be removed, I am saying that both should exist because it should be up to the user to decide what they do or don't want. > a) accidentally clicking the wrong item (as they may alter positions on events out of your control) How about I just use your own argument against you, "If you cannot control where you click, you've more severe and general problems." > b) no contextual info about the (as we agree) destructive nature of your action (you could have forgotton the configuration or accidentally set it - and that *does* actually happen) You do have contextual info for this, because you turned it on. :) If it was a default feature then it would a problem, but it is NOT default therefore your argument is as you like to say "void". > accidentally set it It is behind 8 layers of actions so no it is very unlikely that someone would "accidentally set it". Required Actions: System Settings -> Desktop Effects -> All Effects (tab) -> Present Windows (find this effect) -> open Present Windows Configuration -> Windows section -> "Middle button" drop-down menu -> select "close window". > (Sidenote: I've actually accidentally clicked the middle button because a usb-reconnect of the mouse which reset custom button mapping, I prefer the MMB on the thumb) you've accidentally middle clicked . . . while having this feature enabled, while in Present Windows, and while having your mouse on a window? If no, then not relevant. > You can maybe react in 500ms You don't need to because with a larger hitbox, less movement overall. > Just reverting the patch that removed it is no actual technical challenge For some it is, for some it isn't. KDE is about providing the best user experience, right? "Edit the code and compile it yourself" is not very good approach for user experience. > Please do not take quotes out of context to then imply a different meaning into them. > "[... that] I consider the need to protect the users in general as more important than the custom workflows of a few users. It's impossible to make everyone happy, we have to compromise." > He notably did *not* say "to protect users from themselves", as you insinuated. For someone who cares about not taking out of context, why did you take what I said out of context? I said, "thus you are essentially saying that you are 'protecting people from their own preferences'." The context of what I said shows that I was providing a translated paraphrasing of what Martin said and in no way implied it was quoting him. Take your own advice. ------------------------ @Martin Gräßlin > To move forward I suggest that people interested in this feature try to take it to a higher level. > Feel free to raise this issue with the Visual Design Group [1] - if they tell me this is an absolutely needed feature and the removal was wrong, I might be willing to reconsider. You want us to take it to a "higher level" and if said "higher level" agrees with us and tells you to put it back . . . then you "might be willing to reconsider"? What is the point of going to a higher level if the outcome we can hope for is "I might . . . reconsider". What I perceive from that is if overruled you may or may not reconisder whether you may or may not add it back. If you are willing to say "if overruled then I'll add it back" then ok I will attempt to discuss it with said "higher level" but if you won't then all you are suggesting is for me to potentially waste my time and waste the time of the VDG. > Given that I think this bug report is very frustrating for all of us and we should leave it here and stop the discussion. This discussion is quite frustrating for sure because the side of keeping it has demonstrated in many ways that removal is unnecessary and having it is beneficial. On the other hand, the removal side has provided no valid reason for the removal . . . yea I would call that frustrating. > This bug report has 70 comments and 13 subscribed users. We have millions of users. Please understand that I'm not impressed by those numbers. I agree that in comparison to millions that is not impressive but that is also not relevant because this feature only effects the people who want it and doesn't hurt any of the millions of people who don't use/want it. ------------------------ @Markus P. Leiser I just wanted to thank you for your reply especially in pointing out the aspects of people ignoring solutions and other points in this thread, that has happened a lot in this discussion. I disagree with your comment about "no visual indicator" argument being valid due to personal configuration implies the user already knows about it. Everything you said was considered and refreshing regardless of my agreement or disagreement with it so thank you for commenting. ------------------------ @Martin Gräßlin > I don't think we are moving any way here. I have asked the VDG for a redesign of Present Windows quite some time ago. Let's move that project forward, there won't be significant changes to the current Present Windows codebase anyway. I agree, it should be redesigned . . . but a simple usability feature that effects ONLY the people who want it should not rely on an entire redesign. ------------------------- @Tomasz Kołosowski > I understand that KDE 4 is now feature frozen, so it can't be readded there. Correct. > And from comment #65 I understand that it has been re added to Plasma 5. Incorrect. That comment is showing that another developer provided a choice to the user for a completely unrelated feature, the Icons Only Tasks widget. This does not effect KWin or Present Windows at all.
Why does KDE allow to configure the the middle click action to close for the task bar and the title bar of every window? Why are here so much emotions? Why do you say "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)."? Is this a private feud? Why hurt this feature? In contrast to all the other middle-click-to-close functions?
Could we please stop on this bug report. It won't be added back. There won't be new arguments, so please just let go.
If only you could list reasonable grounds, the discussion would be over. This is requested many times again and again, and you only say "it is mine and I can do whatever I want". It is sad that you fear viewpoints that differ from your opinion. I'd really like to know why this is a red flag for you. If middle click to close is so evil, then why it is possible to configure KDE that way at other places? Nowadays it is usual default behavior to close something by middle-clicking on it.
The discussion is over, I won't implement it and I won't approve any change which would implement it. If you expect reasoning for that: sorry I don't feel like I want to.
The Free Software Movement depends on collaboration: it helps limit duplication of effort while improving the quality of the software produced. In order to avoid misunderstanding, try to be clear and concise when requesting help or giving it. Remember it is easy to misunderstand emails (especially when they are not written in your mother tongue). Ask for clarifications if unsure how something is meant; remember the first rule — assume in the first instance that people mean well. As a contributor, you should aim to collaborate with other community members, as well as with other communities that are interested in or depend on the work you do. Your work should be transparent and be fed back into the community when available, not just when KDE releases. If you wish to work on something new in existing projects, keep those projects informed of your ideas and progress. It may not always be possible to reach consensus on the implementation of an idea, so don't feel obliged to achieve this before you begin. However, always ensure that you keep the outside world informed of your work, and publish it in a way that allows outsiders to test, discuss and contribute to your efforts. Contributors on every project come and go. When you leave or disengage from the project, in whole or in part, you should do so with pride about what you have achieved and by acting responsibly towards others who come after you to continue the project. As a user, your feedback is important, as is its form. Poorly thought out comments can cause pain and the demotivation of other community members, but considerate discussion of problems can bring positive results. An encouraging word works wonders. [https://www.kde.org/code-of-conduct]
Ftr, several issues with closing windows from this effect in general an in particular w/ the previous MMB feature were stated in comments #68 and #71 The original concept of present windows (aka exposé) was that of an alternative window switcher, my personal opinion was and is that the ability to close windows from there should never have been added (you may find some review request of mine to make the close buttons optional) Window management capabilities beyond require a thorough redesign on top of a consistent concept (of something that is not what present windows was) - that implies a rewrite in this particular case (the code is patchwork)
(In reply to Thomas Lübking from comment #86) > Ftr, several issues with closing windows from this effect in general an in > particular w/ the previous MMB feature were stated in comments #68 and #71 Fuchs explained how you were wrong for #68 in #69. I explained how you were wrong with #71 in #80. Just because you do not agree with the feature does not mean your comments are the final say. (In reply to Martin Gräßlin from comment #84) > The discussion is over, I won't implement it and I won't approve any change > which would implement it. If you expect reasoning for that: sorry I don't > feel like I want to. You have now finally admitted what most of us suspected. You removed it because of your own preference, you have no actual reason for removing it, you have no intention to ever put it back and you won't approve any change for it. I'm glad to finally have an answer for a question regarding your comment of asking a "higher-level" that I asked 4 months ago, better late than never. The answer was exactly what I expected so I'm disappointed with your attitude but not surprised. I will go to the "higher-level" now just to get an outsider perspective of the benefits and negatives discussed in this thread. I expect you to ignore them but I will contact them out of principal. Your insistence to dictate what other people should and should not want is just wrong and disappointing whether you ignore the "higher-level" or not won't change the fact that your approach to this subject is poor.
No Fuchs said "right, but can easily be done" and your comment #80 is frankly just a collection of bullshit. Stuff like "you're the only one who thinks so" and turning "you may misclick because things suddenly move under the cursor" into "if you cannot control where you click" made me seriously wonder whether you were not entirely sober when writing this. I'm now really fed up and just deleted the branch fixing my "list of defects" - you may thank Mr. Tunnell for this.
(In reply to Thomas Lübking from comment #88) > turning "you may misclick because things suddenly move under > the cursor" into "if you cannot control where you click" made me seriously > wonder whether you were not entirely sober when writing this. On comment #71 you said and i quote: "If you cannot control where you click, you've more severe and general problems." So it appears you don't remember your own words nor bothered to Ctrl+F. > your comment #80 is frankly just a collection of bullshit You are dismissive in every comment you make as if to say only your comments are valid such as claiming in multiple comments that others' points are "Wrong" or "Void". Calling my comments bullshit because you disagree with them is most certainly not civil and I'd suspect violates the KDE Community Guidelines. > I'm now really fed up and just deleted the branch fixing my "list of > defects" - you may thank Mr. Tunnell for this. That's petty and absurd.
I'm sorry, but > and your comment #80 is frankly just a collection of bullshit. > Stuff like ... made me seriously wonder whether you were not entirely sober when writing this. looks highly unprofessional, as does > I'm now really fed up and just deleted the branch fixing my "list of > defects" - But at least you write this with your real name above it, so I assume you take the full responsibility for your words and behavior. > you may thank Mr. Tunnell for this. Not at all, we will thank you for it. You were the one issuing the command, nobody is to blame for how you react to people having different opinions and voicing them. This is a very childish "last act". However, I think this, together with > I won't implement it and I won't approve any change which would implement it. > If you expect reasoning for that: sorry I don't feel like I want to. is a good summary of how users have been and are being dealt with here. That's a massive shame, I really liked kwin / Plasma. But behavior like this made me finally switch. I hope you will somehow be able to act like responsible adults again. And with these two cents of mine: I'm out.
> The discussion is over, I won't implement it and I won't approve any change which would implement it. If you expect reasoning for that: sorry I don't feel like I want to. You should carefully read and understand this. All of it. https://www.kde.org/code-of-conduct/ > Be pragmatic. KDE is a pragmatic community. We value tangible results over having the last word in a discussion.
hey all, as you now even point me to the code of conduct: The code of conduct does not force me to write code or to review code. So let me explain why I won't implement it and won't let a feature go back in: because I'm sick of this report. Sick of the behavior expressed by the small number of people here. Sick of the accusations thrown at me. It's a waste of my time to comment on this bug report. I just don't want to have anything to do with it any more. The easiest way would be to just let the feature in again, but I don't make maintainer decisions based on bullying by a small number of people. Everything regarding this bug report has been said. There won't be new information going in and nobody of those wanting the feature back, will accept the arguments we presented. So why should we continue to spend time on it? If you think that this is all badly handled and you think I violate the code of conduct I urge you to contact the community working group.
Hello to all participants in this bug report. People on both sides of the issue have asked me to look at it. While things have been very emotional in the debate, I hope all of us agree that we all want what is best for the KDE community and the software we produce. The level of heat here shows that all of us care about that a great deal. The fact remains that those who do the work get to decide, and working *with* maintainers to get your wishes granted works better than antagonizing them. If you have further input, please write to the Community Working Group at community-wg@kde.org. Valorie, for the CWG
*** Bug 403777 has been marked as a duplicate of this bug. ***
*** Bug 273683 has been marked as a duplicate of this bug. ***
Git commit 4dd4ca8f1c44226e0b2fc5e32ca911cc06402480 by Nate Graham. Committed on 21/06/2019 at 16:25. Pushed by ngraham into branch 'master'. [effects/presentwindows] Allow closing windows on middle-click Summary: Plasma's Task manager exposes an optional feature whereby the user can middle-click on a window to close it, but the Present Windows effect does not do the same. The presence of a close button you can left-click does not replace the desirable feature to be able to middle-click on a window to close it, because then the whole window becomes a click target, so it can be much much faster than having to aim for the little close button. Also it's off by default, so a user who goes out of their way to turn it on is signaling that they want to accept the risk of accidentally closing a window by accident. Finally, the feature is not allowed for left-click, so people can never accidentally wreck Present Windows for themselves by assigning it to left-click by accident and then mistakenly closing their windows. This reverts commit 55585514f926d1251148e876bfe9ce3504432997. FIXED-IN: 5.17.0 Test Plan: Set "Close window" in the Present windows effect, trigger effect, and middle-click on window {F6815303} Reviewers: #kwin, davidedmundson, broulik, zzag, #plasma, hein, mart Reviewed By: #kwin, #plasma, mart Subscribers: mart, abetts, apol, zzag, luebking, kossebau, graesslin, kwin Tags: #kwin Differential Revision: https://phabricator.kde.org/D21083 M +5 -0 effects/presentwindows/presentwindows.cpp M +2 -1 effects/presentwindows/presentwindows.h M +10 -0 effects/presentwindows/presentwindows_config.ui https://commits.kde.org/kwin/4dd4ca8f1c44226e0b2fc5e32ca911cc06402480
6 years later, we got it back. You're my hero man, I can't thank you enough.
You're welcome! :)
Yes! I have been waiting for this to happen for over 4 years so I am so excited to see it's finally happening! Thank you! When we eventually meet in person, fair warning . . . hug is coming
I can't believe that we get this truly great feature back soon! Yay! :)
I have maintained my own little patch all these years (https://gist.github.com/DL6AKU/e5cc0e47b61ae0f87171d64fd2dba49d) and FINALLY this is back in KWin! I could not believe it at first because my build would say that my patch was already applied. Looks like your patch is almost identical to mine, Nate. Nice! So as a second though: Is that @*&#! Gräßlin finally gone from KDE (he used to be called Gräßlin, now apparently called Flöser)? And looks like he is! F**k yeah!: https://www.golem.de/news/kde-kwin-maintainer-martin-floeser-tritt-zurueck-1806-134802.html His behaviour was the reason I stopped contributing to KDE all those years ago! Looks like I can contribute now again!
While I understand how frustrating it was to have lost this feature for so long, let's try not to personally insult people. I haven't always agreed with all of Martin's decisions either, but he was a tremendously prolific developer for many years and an able KWin maintainer during difficult times. Let's look forward to an era of civility and respect going both ways between users and developers. That's the way we supercharge Plasma and take over the world! :)
Yeah, but he has a toxic personality and no insight in other peoples viewpoints (as you can see from this bug report and the phabricator one). "Kein Fingerspitzengefühl". I just wish he would own up to it, apologize for his behaviour on this matter and show some empathy in the future.
I'd love to see this re-instated but to alleviate the concerns of the danger of a user closing it the following options: Option 1: - Add the middle click as an option to close (not default). Option 2: - Make middle click to close the default option but the process would be as follows: 1. User middle clicks to close app 2. App is instead hidden temporarily 3. Notification (like when a widget is deleted) allowing users to undo, if chosen app is unhidden. 4. If users doesn't undo action within x seconds the app is then closed
My apologies, I didn't see the comment further up that it had been fixed, have found the setting as well thanks to help in the Telegram group.