https://bugs.kde.org/show_bug.cgi?id=488060
Pedro V <voidpointertonull+bugskde...@gmail.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |voidpointertonull+bugskdeor
| |g...@gmail.com
--- Comment #4 from Pedro V <voidpointertonull+bugskde...@gmail.com> ---
(In reply to Vaclav Fiala from comment #3)
> Here are a few use cases:
> 1) "Cautious / security conscious user" - no new windows should get focus
> initially, except for a few well defined ones (like a terminal app or
> KRunner)
> 2) "Long startup time apps" - define a rule that a specific application that
> has a very long startup time should not get the initial focus (breaks
> workflow)
Can confirm these problems/desires, although I'm not sure the proposed
approaches are the right ones:
1) User interaction is what should matter, a whitelist would be just a flawed
workaround. If I press Ctrl-Alt-T I surely want Konsole right in my face, but
if a background program would start it for some odd reason, I definitely
wouldn't want it to steal focus.
2) Would have to test to get a feel, but I'm not sure I'd want a timeout in
that case. If I wait for the launch then it should get focus anyway, but if I
focus on another window while the program is starting, then I'd be okay with it
not getting focus, no matter how fast it starts. The potentially tricky problem
is starting from KRunner or the the Application Launcher as focus goes back to
the previous window on those cases, and it's not obvious if the user wants to
keep it that way which is the case where I could see the timeout making sense,
although I still wouldn't be a fan of the resulting inconsistency.
I'm not on Plasma 6 yet, so can't test current behavior, but so far I just gave
up on the focus stealing prevention setting. Too low and silly programs pop up
windows while I'm typing, potentially accepting a call almost instantly when
hitting enter for what should be a new line in a text editor, or too extreme
and even child windows appear behind the parent window.
Speaking of security though, there's another important aspect other than
accidental actions taken as mentioned.
Ideally one day we are going to get the "promised" Wayland clipboard security
feature which prevents programs just reading the clipboard whenever they feel
like, even if that's an optional setting for more secure environments. This
requires focus stealing prevention to work properly, so there's no unavoidable
accidental user interaction which would allow clipboard reading (although I
would opt into a strict Ctrl+(Shift)+V only pasting security level if ever
available).
GNOME had something relevant, and wl-paste worked around it with focus
stealing:
https://github.com/bugaevc/wl-clipboard/issues/31#issuecomment-462023847
--
You are receiving this mail because:
You are watching all bug changes.
