Summary: | application launcher problem with focus stealing prevention high | ||
---|---|---|---|
Product: | [Plasma] plasmashell | Reporter: | Andriy Gapon <avg> |
Component: | Application Launcher (Kickoff) | Assignee: | David Edmundson <kde> |
Status: | RESOLVED DUPLICATE | ||
Severity: | normal | CC: | bugs.kde, nate, plasma-bugs, postix, rlk |
Priority: | NOR | ||
Version: | 5.17.5 | ||
Target Milestone: | 1.0 | ||
Platform: | unspecified | ||
OS: | Unspecified | ||
Latest Commit: | Version Fixed In: |
Description
Andriy Gapon
2019-07-08 08:18:13 UTC
It is a dupe. But the argument that "kwin works as intended" and closing it is embarrassingly ridiculous and doesn't solve the problem so I won't just mark it is a dupe. Out of curiosity why do you use focus stealing on high? For me, explained in https://bugs.kde.org/show_bug.cgi?id=377914#c31 In truth, even High isn't really high enough. As I noted, there are situations in which LibreOffice (on a different virtual desktop, no less) manages to steal focus at FSP=High. That's a problem for me, as I noted; I have a spreadsheet that takes several minutes to save, and at some point when it's about finished saving, LibreOffice manages to steal focus. I *really* do not want to be working on something else and abruptly lose focuse to LibreOffice (and have the spreadsheet I carefully saved be trashed by whatever I happen to be typing at the time). But at Extreme the application menu is completely unusable under any circumstances, which is too far. The underlying assumption seems to be that the user is working on one thing at a time, and when an action is taken that creates a new window, that the window will be created and ready for use quickly enough that the user doesn't want to move on to something else while the window is being created (this is also a bit of an issue for KPhotoAlbum for me, with >300,000 photos under management -- I've done a lot of performance tuning work, but it still takes about 10 seconds to start up). My preferred working style is often to jump back and forth between a lot of different things (yes, I know the human factor arguments against it, but whatever), so I want window actions to happen in the background and not interfere with what I'm doing. For that to work, there must be no focus stealing -- I want windows to have to be activated explicitly, by moving the mouse into them (or using ctrl-shift-A to activate). This is strictly speaking superfluous, but just to give you a better idea of how I work, I turn off both click to raise and autoraise -- yes, I often want to interact with a window while I have another window partly on top of it. It's a very fluid way of working, but it also means that it's absolutely essential that nothing else be able to grab focus away from what I'm doing. Re-opened Bug 377914, so marking this as a dupe of it. *** This bug has been marked as a duplicate of bug 377914 *** |