https://bugs.kde.org/show_bug.cgi?id=435170
--- Comment #7 from RedBearAK <redb...@redbearnet.com> --- (In reply to Natalie Clarius from comment #6) > It should be noted that the KWin script acts on any window activation event, > i.e. not only when task switching with Alt+Tab, but also with the task > manager in the panel, clicking on a window directly, or when activation was > requested from another process. Distinguishing how a window was activated is > not possible with the KWin scripting API. > > So if it is desired to have application grouping behavior only selectively, > e.g. only in the Alt+Tab task switcher, and maybe only when the window was > not selected by going from Tab to Grave while holding Alt as described in > the previous comment, that would actually require reimplementing the feature > in the core tabbox code (and wherever else one would want to have this). > > Would this still be desirable? The thing with the Alt+Grave issue is that Alt+Tabbing as many times as you want doesn't trigger a window activation as long as you keep holding the Alt key. But as soon as you press Grave while still holding Alt after doing Alt+Tab, the Grave key press triggers the app switch event, and brings all of the app's windows forward. You can then continue to hold Alt and press Grave as many times as you want, but no other window will be brought forward within the app's stack until you release the Alt key. I would have expected the initial press of the Grave key after Alt+Tab to _not_ produce a window activation, the same way that pressing Alt+Tab doesn't immediately trigger a window switch. And I would want Alt+Grave after Alt+Tab (while holding Alt) to mimic the method in GNOME that allows a single window to be brought forward. If the icon was selected via Alt+Grave rather than Alt+Tab, only that individual window should be brought forward. (The thing that apparently can't be done with just a Kwin script.) GNOME's implementation of this is actually superior to macOS. In macOS the only ways to bring a single window forward are A) right-clicking on the app's Dock icon and selecting from the window list in the context menu, or B) finding a way to make a piece of the desired background window visible behind the current window so that you can click on it with the mouse cursor. You can of course also use these methods in GNOME, but I prefer the predictability and speed of hitting Alt+Tab, Grave, Grave, to zero in on a specific window on those rare occasions that I don't want to bring the whole "application" forward as a group. You could describe this as application-centric task switching with the option to enact a single instance of window-centric task switching if the situation calls for it. The application-centric main task switcher still allows the choice of the specific window to be found more rapidly than typical "show me all open windows" task switching, which can be quite overwhelming with many open windows. (Thus the reason to invent workspaces.) But most of the time the most important thing is to keep app windows together. When I'm working with files I typically want to see multiple locations in different windows and be able to drag/move/copy between them easily without tracking down the sibling windows. Same goes for apps like terminals. What I have going in one terminal is often directly related to what I have in another terminal, so I normally want them to just hang out together. So the way the Kwin script is already working is a _BIG_ piece of the puzzle. -- You are receiving this mail because: You are watching all bug changes.
