https://bugs.kde.org/show_bug.cgi?id=488060
--- Comment #8 from Vaclav Fiala <f...@fedy.cz> --- > Do note though that some users are already upset with Wayland limitations so > the default might never change, but part of what makes KDE so great is the > possibility of customization, so the current overly permissive approach > could be kept as the default option, while business / privacy oriented > setups should be able to opt into the requirement you described. I feel like there is a middle ground here. You could have "special" apps with elevated permissions and specific targeting (so they can't be abused system-wide by any running app.). As a more general case, maybe something like an Android permission model could be implemented. I could (for example) imagine a pupose build "keybord paste" application (less general xdotool/ydotool), that could be used by password managers to type-out the password. They would also need some authentication token for that (so other apps can't abuse them and generate user input). > > User initiation alone is not a good enough requirement though, but it would > be a good start. The earlier described problem of a call popping up while > typing just really shouldn't happen, but the focus on launch problem > satisfies the user initiation requirement while still being an annoyance. Maybe we have a terminology problem here. What I meant by "user initiated action" was some form of user interaction that leads to creation of the new window. (A backgroud running) Krusader popups in my opinion definitely don't satisfy that requirement. Focusing a popup generated by app already in focus is fine. Otherwise I would prefer just some form of "Application requires attention" notification like the highlighted task bar icon we used to have in X11. No automatic focus switch and definitely no workspace / activity switching. A nice rule of thumb (not requiring any specific rules) could probably be following the PID tree. Does the parent process (or more generally any ancestor) currently have focus? If yes we can switch it to the new window, otherwise only the "new window notification" is allowed (and even that should be probably skipped if the new window is on the current workspace & comes partially into view). That should cover even the KRunner / App Launcher case. -- You are receiving this mail because: You are watching all bug changes.
