In the "Window Actions and Behavior" dialog in the "Titlebar Actions" tab the action "Close" can be assigned to many actions, which can lead to data loss. For example an admin could have changed the default behavior to "Close" but the users using the computer are unfamilar with that, then they can easily lose data just by clicking the title bar. It can be reproduced easily, for example: 1. change the left button action in the titlebar from "Raise"/"Activate & Raise" to "Close" 2. click at the titlebar of a window with the left mouse button OBSERVED RESULT The window closes. EXPECTED RESULT The window shouldn't close. Either the action "Close" should be removed from those events to fix this or the actions shouldn't be configurable at all. Of course I'll gladly provide additional information or patches if needed.
(In reply to plane.wander from comment #0) > loss. For example an admin could have changed the default behavior to > "Close" but the users using the computer are unfamilar with that, then they > can easily lose data just by clicking the title bar. Then this admin should be fired I guess. I see nothing wrong with this action. It's not enabled by default.
(In reply to Vlad Zagorodniy from comment #1) > Then this admin should be fired I guess. Ok, but then I'm confused. The window present effect had a similar feature: Middle click on a window to close it. This feature was also not enabled by default but it was removed from KWin for the same reason I gave: What if an admin enables it and its users don't know about it, or what if a friend of yours is using your computer and doesn't know that you enabled it -> This can cause data loss for the users and therefore must be removed. So where is the difference between this feature and the "middle click to close" in the window present effect? > I see nothing wrong with this action. It's not enabled by default. So was the middle click to close feature in the window present effect.
If it were a real issue, then there would be lots of bug reports asking to remove destructive actions. I'm sorry but what you're asking won't be implemented. So, stop wasting your and our time.
(In reply to Vlad Zagorodniy from comment #3) > If it were a real issue, then there would be lots of bug reports asking to > remove destructive actions. There also wasn't a single bug report asking to remove the same destructive actions from the present windows effect, yet it was removed proactively. I just want to do the same here, so KWin is behaving in a consistent way. Or, if it is considered ok to have this sort of destructive actions available when disabled by default I'm also willing to add the feature back to the present windows effect. > I'm sorry but what you're asking won't be implemented. So, stop wasting your > and our time. So it's ok if I submit a patch to add the same functionality back to the present windows effect, because the reasons to remove it in the first place aren't considered valid any more? I mean it has to be one or the other: Either it's bad to have this sort of destructive actions to close windows or it's fine as long as they are disabled by default.
(In reply to plane.wander from comment #4) > So it's ok if I submit a patch to add the same functionality back to the > present windows effect, because the reasons to remove it in the first place > aren't considered valid any more? I mean it has to be one or the other: > Either it's bad to have this sort of destructive actions to close windows or > it's fine as long as they are disabled by default. FWIW, I would support this, for just the reasoning you give. Makes sense to me, can't have it both ways.