https://bugs.kde.org/show_bug.cgi?id=377914
--- Comment #42 from r...@alum.mit.edu --- Comment #40 really makes my blood boil. Reduced to its essentials, "it doesn't matter how much pain it's causing the users, the rules come first". I will admit that there are times when the rules are there for a good reason, and they actually do benefit the end users even if that's not recognized. For example, a 2 factor authentication app I use does not allow backing up or restoring tokens to a device. That's generating a number of user complaints, but it's actually the right thing: being able to back up and restore tokens would allow cloning the token, violating a basic assumption behind two factor authentication, that the token is unique and allowing a big security hole. There are also times when a fix might simply be too costly in engineering resources (perhaps preventing fixing more critical issues) or where a seemingly simple fix would have non-obvious consequences that would result in even more difficulty. As best as I can determine, though, none of these circumstances apply. There's no security (or other critical, from a product standpoint) hole that this would open (quite the reverse, actually); there is an easy fix (a window-specific rule), and there are no consequences (e. g. unexpected bad behavior) that would result from this change. The reasoning is presented solely in terms of project rules and the desire to maintain perfect consistency with said. If there are unexpected consequences, I invite Martin to present them. I recall a discussion I had on another window management issue I was having with focus stealing prevention and focus under/strictly under mouse, where the assignee of the bug explained why focus stealing prevention inherently is not compatible with focus strictly under mouse, and the simple expedient of using focus follows mouse (which isn't quite what I want -- I also want a window to lose focus if I move the mouse outside it -- but it's seemingly close enough). I wasn't too thrilled, but I received an explanation of why what appeared to me to be straightforward actually wasn't what I thought it was. But this response is quite different -- it refers solely to strict internal project rules, and makes no attempt to demonstrate any unexpected user harm or even to note particular difficulty in implementing a fix. That's simply not a satisfactory answer. -- You are receiving this mail because: You are watching all bug changes.
