Version: (using KDE KDE 3.4.0) Installed from: SuSE RPMs OS: Linux When focus stealing prevention is set to extreme, windows generally seem to pop UNDER my other windows and I must go hunt for them. This is even worse if an application has gotten itself stuck and is displaying an app-modal dialog but the dialog is hidden under some other window. Might I pretty-please request that a preference be added whereby new windows are not given focus, just as in the extremem focus-stealing mode today, BUT they DO get raised to where I can see them? The focus-stealing prevention was (imo) one of the best usability enhancements kde got in 3.4 ... If I could just get the new windows to raise automatically, I'd figure the feature was just about perfect... [And yes, despite reading what related posts I could find, and looking thru all the kde config screens I could find... please forgive me if there's a solution or resolution to this that I missed.] Thanks.
Should be rather simple, just grepping kdebase/kwin/* for 'allowClientActivation' and 'allowFullClientRaising' should show all the places where focus stealing prevention is considered.
Cross reference bug #105523 - request for similar capability.
*** Bug 105523 has been marked as a duplicate of this bug. ***
Yes please, make this happen! Junior, there's a job for you!
FWIW, using Gentoo's KDE 3.4.1, this is also a problem with Low focus stealing prevention: new windows often appear hidden, with only the taskbar as a hint that they exist. Bug 101296 addresses this same issue in a different manner.
Created attachment 18593 [details] A patch with a brute-force fix I have sat on this for a Long time, but when I recently got a new laptop and put Kubuntu Edgy on it, Gaim 2.0 finally forced me to take action: I have patched my laptop locally with the attached patch for KDE 3.5.5 (before the Kubuntu patches) What I've done is replace the Workspace::allowFullClientRaising() function - to make any Focus Stealing Prevention mode less than "Extreme" still allow a window to take the foreground. (that way there is a way to remain uninterrupted) What I would really appreciate from anybody else that cares and knows how (I don't) is to make this an option with a GUI instead of simply replacing the current behavior entirely. That way there would be a chance it could actually make it into KDE. And a big thank you to Lubos Lunak in bug 110543 for pointing out this starting point.
Created attachment 26000 [details] Update of brute-force patch for KDE 3.5.8 and 3.5.9 Here is an update to the patch made with KDE 3.5.8 that also works with .9 with no change. Is there a 'proper channel' someone can point me to in order to ask a knowledgeable KDE dev to help this bug by expanding it to be an option? (Preferably with GUI) I'd also be willing to pay a bounty on this. This is of course a moot point if the bug is already fixed in KDE 4 (haven't tried it yet) but I suspect that it's not.
*** Bug 276696 has been marked as a duplicate of this bug. ***
*** Bug 198931 has been marked as a duplicate of this bug. ***
from bug #181665 ----------------------- Oswald Buddenhagen 2009-01-23 15:15:37 UTC instead of just preventing a window from getting focus completely, kwin could activate it as usual but overlay it with a lock window. the lock would go away only after a configurable amount of time (.5-1 sec by default) without button and key clicks. that way dialogs would get the attention they deserve, but would not risk having bogus data (usually a premature confirmation) entered into them. ideally, the overlay would be semi-transparent and would have a countdown blended into it. :-) i think it might be even reasonable to make that the default behavior for dialogs (as opposed to "proper" windows).
*** Bug 181665 has been marked as a duplicate of this bug. ***
This issue also exists with High focus stealing prevention in both 4.8 and 4.9. What appears to currently happen is that new windows are always created beneath all other windows, not just beneath the currently active window. My personal preference for behavior would be: 1) Try to create the new window in real estate not occupied by the active window, above any other windows. 2) If that is not possible, create it immediately below the active window and above everything else (leaving it inactive). 3) If there is no real estate not occupied by the current window, and the current window is maximized but not "full screen", create it above the current window but without receiving focus (this one may be more controversial).
Also see this brainstorm: http://forum.kde.org/viewtopic.php?f=83&t=101833
*** Bug 316468 has been marked as a duplicate of this bug. ***
pre-emptive tagging. i recently started research on activation and want to work on that the next days. can end up in a patch ready for 4.11 and i don't want to loose that for a missing tag ;-)
*** Bug 167615 has been marked as a duplicate of this bug. ***
*** Bug 304746 has been marked as a duplicate of this bug. ***
All right, let's see if I can describe more precisely what I want here. In general, I want either focus under mouse or focus strictly under mouse, but with one exception that I'll get to below, in rule 5. New clients should never receive focus, under any circumstances whatsoever, unless no client currently has focus. If no client currently has focus, and the new client is under the mouse, then (and only then) should it receive focus. Placement of new clients should follow these rules, in order: 1) If there is empty space sufficient for the new client, place the client there. 2) If there is sufficient space not used by the client currently with focus, place the new client there on top of any other windows (other than, of course, always on top windows, but try to avoid those as much as possible). 3) If there is any significant (we can argue over the definition of that) space not used by the client currently with focus, place the new client such that it uses as much of the space not used by the current client as possible, place the new client there beneath the current client and on top of all other windows (other than, of course, always on top windows, but try to avoid those as much as possible). 4) If there is no significant space not used by the current client, place the new client on top of the existing one, avoiding the current pointer position if possible. 5) If it is not possible to place the new client such that it is not under the mouse, place it above the current client but DO NOT CHANGE THE FOCUS. This is the sole exception to focus under mouse/focus strictly under mouse. The new window does not receive focus until I take an action to raise it (click on the title bar, use a keyboard accelerator to raise it, or the like).
Did you bother to read the brainstorm post or the attached review requests? https://git.reviewboard.kde.org/r/110918/ https://git.reviewboard.kde.org/r/110919/ (this one is linked as review reuqest to this bug...)
Yes, I did read it. And it doesn't appear to do what I describe.
Laaving aside that most of your calls are about placement and not about focus stealing .... (In reply to comment #18) > New clients should never receive focus, under any circumstances whatsoever -> Extreme focus stealing prevention, though below only holds for "High" where "High" only allows clients to transfer the focus from one window to another (eg. when you trigger a filedialog etc.) by the assumtion that the client knows better. Dialogs (unless ruled differently) are also placed on their mainwindow (to hint the relation) - you'd have to reason why you want to deal such alike as completely unrelated (in position and focus stealing prevention) > If no client currently has focus, and the new client is under the mouse, > then (and only then) should it receive focus. And why? If no client currently has the focus, the new client can have it - regardless whether it (randomly!) appears below the mouse. Actually that's a major difference between FFM and F(S)UM: the client does *not* get the focus (by distribution) because it randomly appears under the mouse. It has to pass FSP instead. --- Off topic, nevertheless: > 1) If there is empty space sufficient for the new client, place the client > there. Smart placement strategy. > 2) If there is sufficient space not used by the client currently with focus, > place the new client there on top of any other windows (other than, of > course, always on top windows, but try to avoid those as much as possible). Raising on top of non active windows presently happens anyway. Keep above windows are avoided more than others by the smart placement strategy because you can't raise above them. Avoiding the active client is - to a certain degree - done by https://git.reviewboard.kde.org/r/110918/ It avoids the mouse if a window is below. > 3) If there is any significant (we can argue over the definition of that) No, because it's a buzzword. > space not used by the client currently with focus, place the new client such > that it uses as much of the space not used by the current client as > possible, place the new client there beneath the current client and on top > of all other windows (other than, of course, always on top windows, but try > to avoid those as much as possible). > > 4) If there is no significant space not used by the current client, place > the new client on top of the existing one, avoiding the current pointer > position if possible. Those are insufficient because the client can demand a specific position, bypassing placement. Falls into "Avoid active client as mus as possible" of (2) Raising based on how much of the new client would be stashed by the active client (and how much the new client would cover the active client) is implemented in https://git.reviewboard.kde.org/r/110919 (covers 3/4 minus their elements that are 2 anyway) > 5) If it is not possible to place the new client such that it is not under the mouse, place it above the current client Why that? If a maximized window opens, if cannot avoid the mouse and because of that should cover also a small window you're currently pointing with the mouse and might click into the very next mement? > but DO NOT CHANGE THE FOCUS. Ok, let me shout back: THIS DEPENDS ON THE FOCUS STEALING PREVENTION LEVEL ANYWAY So your list boils down to mentioned patches, but the active client should be extra avoided (as mouse or keep above windows) and you'd prefer to transfer High FSP raising strategy to Extreme as well (do you actually, given above explanation?) Also two open questions about mouse/raising/focus relation (where i completely fail to see the reasoning behind) Correct?
(In reply to comment #21) > Laaving aside that most of your calls are about placement and not about > focus stealing .... > > (In reply to comment #18) > > New clients should never receive focus, under any circumstances whatsoever > -> Extreme focus stealing prevention, though below only holds for "High" > where "High" only allows clients to transfer the focus from one window to > another (eg. when you trigger a filedialog etc.) by the assumtion that the > client knows better. > Dialogs (unless ruled differently) are also placed on their mainwindow (to > hint the relation) - you'd have to reason why you want to deal such alike as > completely unrelated (in position and focus stealing prevention) That (I think) is why I suggest high rather than extreme -- to allow clients to transfer focus between themselves. > > If no client currently has focus, and the new client is under the mouse, > > then (and only then) should it receive focus. > And why? If no client currently has the focus, the new client can have it - > regardless whether it (randomly!) appears below the mouse. > Actually that's a major difference between FFM and F(S)UM: the client does > *not* get the focus (by distribution) because it randomly appears under the > mouse. It has to pass FSP instead. I suppose...but if I'm using focus under mouse, that's where it should stay. Although I guess the exception I suggest is more like focus follows mouse (in that one special case). > --- > > Off topic, nevertheless: > > > 1) If there is empty space sufficient for the new client, place the client > > there. > Smart placement strategy. Right. > > 2) If there is sufficient space not used by the client currently with focus, > > place the new client there on top of any other windows (other than, of > > course, always on top windows, but try to avoid those as much as possible). > > Raising on top of non active windows presently happens anyway. > Keep above windows are avoided more than others by the smart placement > strategy because you can't raise above them. It didn't appear to be happening. If I tried to use Configure Desktop on the KDE menu, it got popped under other inactive windows. > Avoiding the active client is - to a certain degree - done by > https://git.reviewboard.kde.org/r/110918/ > It avoids the mouse if a window is below. OK. > > 3) If there is any significant (we can argue over the definition of that) > No, because it's a buzzword. > > > space not used by the client currently with focus, place the new client such > > that it uses as much of the space not used by the current client as > > possible, place the new client there beneath the current client and on top > > of all other windows (other than, of course, always on top windows, but try > > to avoid those as much as possible). > > > > 4) If there is no significant space not used by the current client, place > > the new client on top of the existing one, avoiding the current pointer > > position if possible. > > Those are insufficient because the client can demand a specific position, > bypassing placement. That's the "if possible". Client demanding a specific position can make it impossible. > Falls into "Avoid active client as mus as possible" of (2) > Raising based on how much of the new client would be stashed by the active > client (and how much the new client would cover the active client) is > implemented in https://git.reviewboard.kde.org/r/110919 (covers 3/4 minus > their elements that are 2 anyway) > > > 5) If it is not possible to place the new client such that it is not under the mouse, place it above the current client > Why that? So that I can at least see it. With FFM+high stealing prevention, I find a lot of popup windows get lost, sometimes to my embarrassment (e. g. IM's from coworkers). > If a maximized window opens, if cannot avoid the mouse and because of that > should cover also a small window you're currently pointing with the mouse > and might click into the very next mement? Then let me amend it: if the new window would be completely covered by the client with focus, open it above that client so I can see it. If not, open the new one below the old -- but make sure that some of the new client is visible so I know it's popped up. > > but DO NOT CHANGE THE FOCUS. > Ok, let me shout back: THIS DEPENDS ON THE FOCUS STEALING PREVENTION LEVEL > ANYWAY Right: and my preference is for a very high level of focus stealing prevention. > So your list boils down to mentioned patches, but the active client should > be extra avoided (as mouse or keep above windows) and you'd prefer to > transfer High FSP raising strategy to Extreme as well (do you actually, > given above explanation?) > Also two open questions about mouse/raising/focus relation (where i > completely fail to see the reasoning behind) > Correct? I guess that what I'm getting at is that a new client should never (in my view, and if that's technicallly called extreme FSP, fine) result in a focus change. To the greatest extent practicable, it should not interfere with the current window with focus. But it needs to be very clear that a new window has opened. If I could rely on the task manager flashing continuously for attention until I activate the new window, that might work. But I want to be aware that a new window has opened. I just don't want it actually changing focus (yes, even if nothing currently has focus). I guess you could call it old-fashioned xwm (predates twm) style, but with FSP.
(In reply to comment #22) > I suppose...but if I'm using focus under mouse, that's where it should stay. Yeah, but if it's currently nowhere, it can just be passed to the new window (regardless on whether the mouse is over the window) - a bit more like FUM than FSUM - since the focus "transfer" (from nowhere to the new window) will not disturb any action. > > Raising on top of non active windows presently happens anyway. > It didn't appear to be happening. If I tried to use Configure Desktop on > the KDE menu, it got popped under other inactive windows. Yes, happens Reason is that the restacking restacks under all clients in the group of the active one, what for the currently active (the kickoff menu) also includes the desktop .... -> https://git.reviewboard.kde.org/r/112627/ > Then let me amend it [...] Yes, that is provided by the stash management. The only remaining problem is if you got an active maximized window and a new window opens (nearly or really) maximized, ie you'd more or less stash the active window under the new window. I doubt this is a resolvable conflict and believe we need some other way to hint it (like using the compositor, sending a notification or blink the taskbar) > I guess that what I'm getting at is that a new client should never (in my > view, and if that's technicallly called extreme FSP, fine) Depends on the definition of never: if not event focus transfers inside clients are permitted, that's "extreme" - otherwise it's "high" and the two patches linked before actually will cause this (for "high") minus the conflict case (max'd ./. max'd) Keeping the new window away from the active window is reasonable since it lowers the chance of a stash collision (esp. for click-to-focus) so the resp. patch should be extended by that. Feel encouraged to test the patches and provide feedback.
*** Bug 324845 has been marked as a duplicate of this bug. ***
Git commit 99db09bbc8db6623f6b166b074910358c84c3226 by Thomas Lübking. Committed on 09/09/2013 at 20:38. Pushed by luebking into branch 'KDE/4.11'. group aware restack accounts layer compatibility the restack code stacks under all members of an application this is a problem if the group contains a keep below or desktop etc. (while the other window is a normal one) what resulted in restacking the client "invalidly" above the window of the other layer but below all other memberso of its own group for no reason REVIEW: 112627 M +2 -2 kwin/layers.cpp http://commits.kde.org/kde-workspace/99db09bbc8db6623f6b166b074910358c84c3226
*** Bug 206591 has been marked as a duplicate of this bug. ***
(In reply to Thomas Lübking from comment #25) > Git commit 99db09bbc8db6623f6b166b074910358c84c3226 by Thomas Lübking. > Committed on 09/09/2013 at 20:38. Excellent. But where is this fix? We're 15 years after 2008. Also, where is "smart placement" The Settings -> Window Behavior -> Advanced menu doesn't have that option. I can't screenshot the menu 'cuz you disable that when menus are open, but I've set it to "minimal overlapping". Is that the same? In summary, if the implementation has wandered away from the descriptions here, maybe some updates about it? Just a note so folks happening by here aren't left wondering how to enable "smart placement" when there isn't such a thing.