I use a configuration similar to Mac, where Alt+Tab will cycle Applications, and then Alt + ` will cycle occurrences of that application. The issue is that when you go to an application, and close that window, you don't get the other window of the same application focused, instead of the previous *window* that was in the Alt + Tab list. This is better explained with an example, and what would be expected (assuming Alt+Tab is already configured with the "Only one window per application" chosen): 1) Open Dolphin 2) Open Kate 3) Hit "Ctrl + O" to have the "open file" dialog open 4) Alt+Tab to switch to Dolphin 5) Alt+Tab to switch back to Kate (you should be at the "Open file" dialog) 6) Either open a file or just close the dialog What happens now, is that you end up back at Dolphin, instead of the Kate document. Second example: 1) Open Chromium 2) Ctrl + N to get a new window 3) Open Konsole 4) Alt + Tab to Chromium 5) Ctrl + W to close this window At this point, instead of being at the first window of Chromium, you go back to Konsole. When choosing "Only one window per application", Alt+Tab should stack all windows of the same application together, and not just windows on their own order.
dev note (regardless of the wish) activateNextClient() desires to pass the focus from transients to their leaders anyway what however largely fails (eg. in this kate/open dialog case) because the windows have a groupTransient() and thus no direct transient - and the group transients are not considered. => we could instead check whether the client->isTransient() and iterate over its client->mainClients() to check for isUsableFocusCandidate()
Git commit cfa1d612fea363ef1b5e73c9c49f6499f4320083 by Thomas Lübking. Committed on 15/05/2015 at 21:55. Pushed by luebking into branch 'master'. Prefer singleton transient leader on activateNext instead of "just" the direct transient. Reason is that many windows set dialogs transient for an entire group (eg. all their document windows) If there's only one window, that is equivalent to choosing the direct transient leader. Originally I wanted to allow this for any amount of leaders and picked the first one, but that means if you open 2 kwrite windows (from one PID!) and an open dialog for kwrite #2 and close the latter, the focus would be passed to kwrite #1 -> The focus chain is the better choice here. (One could look up all leaders in the focus chain OR the stack and use the most recent/top one, but that's probably voodoo) REVIEW: 123691 M +8 -4 activation.cpp http://commits.kde.org/kwin/cfa1d612fea363ef1b5e73c9c49f6499f4320083
(In reply to Franco Pellegrini from comment #0) > 1) Open Dolphin > 2) Open Kate > 3) Hit "Ctrl + O" to have the "open file" dialog open > 4) Alt+Tab to switch to Dolphin > 5) Alt+Tab to switch back to Kate (you should be at the "Open file" dialog) > 6) Either open a file or just close the dialog > > What happens now, is that you end up back at Dolphin, instead of the Kate > document. On Wayland Kate editor is in foreground - covering the focused but foregrounded Dolphin Operating System: KDE neon Developer Edition KDE Plasma Version: 5.14.80 Qt Version: 5.11.1 KDE Frameworks Version: 5.51.0 Kernel Version: 4.15.0-34-generic OS Type: 64-bit Processors: 8 × Intel® Core™ i5-8250U CPU @ 1.60GHz Memory: 7,7 GiB of RAM
Thank you for reporting this issue. I tried to reproduce the steps but the described behavior works for me. Is this still an issue for you in 5.24.5?
(In reply to kde.org from comment #4) > Thank you for reporting this issue. I tried to reproduce the steps but the > described behavior works for me. Is this still an issue for you in 5.24.5? I haven't yet upgraded to 5.24.5, I am on 5.24.4 and this is still happening by following my second example: 1) Open Chromium 2) Ctrl + N to get a new window 3) Open Konsole 4) Alt + Tab to Chromium 5) Ctrl + W to close this window It no longer happens though, with the Kate example with the "Open" dialog
Thank you for the quick response. I still can't reproduce the issue. What focus policy are you using. I use "focus follows mouse (mouse precedence), focus stealing prevention medium.
(In reply to kde.org from comment #6) > Thank you for the quick response. I still can't reproduce the issue. What > focus policy are you using. I use "focus follows mouse (mouse precedence), > focus stealing prevention medium. Same settings on both... Are you using your mouse to change focus? Try this, without touching your mouse at all: 1) Alt + Space, type Konsole and open it 2) In konsole Type some random character, say "1", doesn't matter, and hit Enter. 3) Ctrl + Shift + N to open a new Konsole Window 4) Type a different character, say "2" and hit Enter. 5) Alt + Space, type Dolphin and open it 6) Alt + Tab to switch to Konsole (You should be seeing the one you typed 2) 7) Ctrl + D to close it At this point, you are back at dolphin, and not at the Konsole with "1"
I did exactly what you wrote and not touch the mouse and can confirm that I am back at dolphin. But to be honest, that's what I would have expected, as that is the window that was active before tabbing to Konsole 2. Your wish is that this behavior should be changed to move the focus to the most recent active window of the same application, when "Only one window per application" is chosen for the tabbox. Well, I'll leave that for someone else to decide if the behavior should be changed or if we need a new config option to enable your desired behavior.
(In reply to kde.org from comment #8) > I did exactly what you wrote and not touch the mouse and can confirm that I > am back at dolphin. But to be honest, that's what I would have expected, as > that is the window that was active before tabbing to Konsole 2. Your wish is > that this behavior should be changed to move the focus to the most recent > active window of the same application, when "Only one window per > application" is chosen for the tabbox. Well, I'll leave that for someone > else to decide if the behavior should be changed or if we need a new config > option to enable your desired behavior. Correct, there are 2 ways you can look at this, either you Alt + Tab between applications or windows... If you switch between windows, then yeah the current behavior is expected, I am proposing to provide a way to really Alt + Tab between applications (Which is the intention, I believe of the "Only one window per application). When I created this proposal, I was coming from MacOS, and I am pretty sure the behavior was like what I am proposing here (I don't remember, this report is turning 7 years in a few days :P, and I don't have a Mac near me to test), which does make a lot of sense when you work with tons of windows/tabs/etc... At least it does for me :) I am fine with it being either the default behavior or having a separate setting, it would be great either way.
This behavior is now available as an extension: KWin Script "Application Switcher" https://store.kde.org/p/1805105