https://bugs.kde.org/show_bug.cgi?id=377914
--- Comment #38 from r...@alum.mit.edu --- The behavior may be correct according to the spec and the implementation of the panel (as a window that never gets focus), but it's completely nonsensical from a user perspective to have core functionality (application launcher or application menu won't work when focus stealing prevention is enabled). It may meet the letter of the UI spec, but if that's the case the spec is flawed from a user experience perspective. (Incidentally, one workaround is to use focus under mouse or focus strictly under mouse, but those have their own problems and I believe they are considered "unreasonable". The other workaround, with focus follows mouse/mouse precedence) The question I wish to ask the development team is "how can the user avoid getting new windows popped up over existing work or otherwise stealing focus away from whatever the user happens to be doing, without losing the ability to use the application menu or application launcher?" If the answer is in fact "there is no way to get both", then something's very wrong. The app menu is basic KDE functionality; not having windows pop up over what you're doing is a thoroughly rational thing to want (you don't want to be entering a password and something suddenly grabs focus, and you don't want to be typing C-a C-x C-s in emacs (which keystrokes mean "go to the beginning of the line (C-a)" and save (C-xC-s), only to have something suddenly grab focus, interpret it as select the entire document, cut it all, and save. If the answer is "write a window specific rule to do this", that's OK *IF* that rule, along with other similar rules needed to achieve rational (from a human non-developer perspective), is present by default. There's nothing fundamentally wrong with implementing behaviors as rules within the confines of the system; that can have the advantage of being easier to change than something hard-coded. Put another way, would you accept a (hypothetical) pull request for an addition of said rule? But expecting ordinary users to understand "window-specific rules", and what constitutes a plasma dialog and how to describe it within those rules, is simply not in my view a reasonable expectation. It requires them to have deep knowledge of how window systems work, which if one is not a developer of window systems, is not something most people care to have to learn. In summary, while the behavior may meet the specification (and "resolved/won't fix" therefore being technically correct), there's still a major problem here that by all evidence (the number of people commenting on this bug, all saying essentially the same thing) is a very strong indication that something is wrong here. -- You are receiving this mail because: You are watching all bug changes.
