Coming from the Mac world, I also find this style of switching to be intuitive and pleasant, and would appreciate seeing it as an option. It mostly only makes sense when using "One window per application" mode, so perhaps it could be a sub-potion only enabled when the aforementioned option is in use.

(In reply to Nate Graham from comment #1)
> Coming from the Mac world, I also find this style of switching to be
> intuitive and pleasant, and would appreciate seeing it as an option. It
> mostly only makes sense when using "One window per application" mode, so
> perhaps it could be a sub-potion only enabled when the aforementioned option
> is in use.

Agreed, in principle. 

I think it would actually be much better ultimately (someday) if there was a very clear and intuitive delineation between the window-centric and application-centric task switching models, with a simple way for the user to say, "Use application-centric task switching", which would then enable whatever features are needed for the switching to be application-centric rather than window-centric. 

Like a button that toggles between: 

Switch Between Windows
Switch Between Applications

But for now I'm sure the simplest way to add the feature would be a sub-checkbox option like "Group application windows when task switching". Something like that. 

I'm trying to think of a situation where a user might want to disable "Only one window per application" but still enable "Group application windows when task switching". But you're right, that really wouldn't make much sense. So a sub-option sounds good. 

I feel like "Only one window per application" should actually be named "Only one icon per application" since that's the most visibly obvious thing it does from the user's perspective. I can't see how its current name really tells the user what it does in any meaningful way. 

If you can actually get this working, sometime this side of eternity, that would be fantastic. Game changing. I doubt we will be alone in enjoying the option.

There is another desktop environment that has the ability to have both "Switch windows" and "Switch applications" active at the same time on different keyboard shortcuts. 

It is possible that some users would have a use case where they would want to have application-centric task switching on one workspace, and window-centric task switching on a different workspace. 

It would be sad if KDE couldn't do the same thing. So the ideal way to implement the fix for this feature request would actually be to allow the user to designate one keyboard shortcut that activates "window switching", where each window is treated as a separate entity, and a different keyboard shortcut that activates "application switching", where application windows are treated as a linked group. 

The two different modes on this other desktop environment each have their own task switcher dialog that comes up. The "Only one window per application" option that currently exists should only apply to the "application switching" mode of the task switcher dialog.

I implemented this feature as a KWin script (with the OP's support): https://store.kde.org/p/1805105

The Kwin script from Natalie is working great after compensating for some interference with panel items. 

Windows of a single application are kept together and brought forward when clicking on any window of the app, or Alt+Tabbing to the app's icon. 

This functionality should be integrated into Plasma, along with a modified task switcher dialog. Like "Large Icons" but with the added ability to transition from Alt+Tab to Alt+Grave to pick an individual app window instead of bringing the entire app window group forward.

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?

(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.

> But as soon as you press Grave while still holding Alt after doing Alt+Tab, the Grave key press triggers the app switch event

What's the problem with that exactly? You can still switch back to a different application with Alt+Tab, and you can switch to a different window being pulled to the front with Alt+Grave.

(From the thread on GitHub https://github.com/nclarius/kwin-application-switcher/issues/2)

> I don't know how even a modified task switcher could bring back the ability to optionally choose a single window to isolate and bring forward. 

The idea is that the implementation would be moved from a KWin script, which just picks up a signal that a window was activated and catches up on the other ones, to the task switcher itself, which knows what keys are being pressed and could decide whether or not to also bring other windows forward on its own accord.  

But what you're saying is that the functionality should be ported to core KWin for the task switcher component but deliberately be broken in the case of using Alt+Grave in conjunction with Alt+Tab, and I'm not sure that's what most users who would like to use this option would expect and want.

(Also from the GitHub thread)

> Of course the user can choose to use a thumbnail switcher at all times, but "app switching" only really makes sense with the somewhat strange "Only one window per application" KDE task switcher option enabled, which makes everything weird. 

Why? What is weird about this option?

(In reply to Natalie Clarius from comment #8)
> > But as soon as you press Grave while still holding Alt after doing Alt+Tab, the Grave key press triggers the app switch event
> 
> What's the problem with that exactly? You can still switch back to a
> different application with Alt+Tab, and you can switch to a different window
> being pulled to the front with Alt+Grave.
> 

Main way I can respond to that is by mentioning how I have "Show selected window" disabled. I don't like the way the screen keeps changing when that is enabled. And most desktop environments in Linux or otherwise don't switch to a window when you are Alt+Tabbing until you release Alt. So it's just odd that Alt+Grave would instantly bring that app's windows forward as if you had pressed Alt+Tab and released Alt already. Alt+Grave doesn't pull each individual window forward as you cycle through with additional Grave presses. In other words, it acts like Alt+Tab, waiting for you to decide which window you want before performing an action, except for the very first time you press Grave after Alt+Tab, when it instantly performs an action. The behavior just doesn't feel consistent and predictable. There is no opportunity to Escape without performing any action at all. 

> The idea is that the implementation would be moved from a KWin script, which
> just picks up a signal that a window was activated and catches up on the
> other ones, to the task switcher itself, which knows what keys are being
> pressed and could decide whether or not to also bring other windows forward
> on its own accord.  
> 

Yes, that sounds like a solution. 

> But what you're saying is that the functionality should be ported to core
> KWin for the task switcher component but deliberately be broken in the case
> of using Alt+Grave in conjunction with Alt+Tab, and I'm not sure that's what
> most users who would like to use this option would expect and want.
> 

I'm not aware of asking for anything to be broken. I probably just worded something wrong. 

> (Also from the GitHub thread)
> 
> > Of course the user can choose to use a thumbnail switcher at all times, but "app switching" only really makes sense with the somewhat strange "Only one window per application" KDE task switcher option enabled, which makes everything weird. 
> 
> Why? What is weird about this option?

How to explain? 

It's weird because when you enable that option the task switcher will only show a single icon/preview for each "application", no matter how many windows that app has open. It may or may not be a window preview that does a good job representing the whole application. 

Application-centric task switching like macOS really treats each application as a monolithic entity, and so such paradigms usually choose to simply show a large application icon for each application, instead of a thumbnail preview of any particular window. Thumbnail sized window previews often look substantially similar, even for completely different applications. Application icons, on the other hand, often look very different from one another. So split-second "app switching" decisions become much easier on the brain, requiring less visual analysis. 

When you have the "Only one window" option disabled while also trying to use "app switching" as the main task switching paradigm, you give up the simplicity of seeing just a single easily distinguished icon in the task switcher. Which, to me, is one of the primary benefits. If you have six "applications" running and each has 10 windows open, that's 60 icons (or tiny thumbnails) in the task switcher dialog with a window-centric task switcher. But only six icons in an application-centric task switcher dialog. It completely changes the act of task switching, and the mental model of task switching. 

This was a completely alien way of thinking when I first transitioned from Windows/Linux and started spending most of my time in macOS. It took me a long time to let go of the idea that I was being "limited" by not being able to see all of the open windows on the whole system in the task switcher dialog. But as you can see, I changed my mental model eventually, and learned to work with it. Now I really dislike task switchers that try to show me dozens of almost useless window thumbnails, or even take over the whole screen trying to make the thumbnails big enough to be usable. 

Pop_OS! does a similar bad thing where it forces the use of the one-icon-per-app task switcher, but completely breaks the ability to actually switch to that "application" as a window group. They apparently did not like the visual complexity of the GNOME "Switch windows" task switcher mode that shows all open windows as thumbnails, but they rejected the logic of treating the windows as a group the way that "Switch applications" normally does. Bug reports were rejected without fixing the issue. 

In the same way, the KDE option "Only one window per application" attempts to mimic an application-centric visual task switch_ER_ without also mimicking application-centric logical task switch_ING_. So to me, it produces a very dissonant, mentally irritating way of task switching. 

Which is mostly fixed by the Kwin script.

Re. §1: Okay, I hadn't thought about disabling the preview.
The transition from Tab to Grave already activating the window before releasing Alt is an issue on its own though, so I suggest you file a separate bug report about it.

Re. §3: What I meant by "broken" was that you're asking to not have the auto-raising in the scenario of switching from Tab to Grave, when you otherwise do want to have it as part of the tab switcher. This sounds unpredictable to me; but I wouldn't know, I wouldn't use the application group feature myself at all, so I'm asking what others (besides you) think.

Re. §4: Okay, this no longer being weird with the script resolves my confusion.

(In reply to Natalie Clarius from comment #10)

> The transition from Tab to Grave already activating the window before
> releasing Alt is an issue on its own though, so I suggest you file a
> separate bug report about it.
> 
Yes, I think I should probably do that. I do consider it a bug. 

> Re. §3: What I meant by "broken" was that you're asking to not have the
> auto-raising in the scenario of switching from Tab to Grave, when you
> otherwise do want to have it as part of the tab switcher. This sounds
> unpredictable to me; but I wouldn't know, I wouldn't use the application
> group feature myself at all, so I'm asking what others (besides you) think.
> 
I think we're still not quite on the same page with this part. The tab switcher doesn't act until Alt is released. You can even hit Escape to make it go away without performing any action. Isn't that how Alt+Tab works for you, if you don't release the Alt key? 

I guess having "Show selected window" active, which it is by default, may make this lack of instant action far less obvious, and vice versa if you disable it the lack of action should be far more obvious. There is definitely no true, final "action" by Alt+Tab until Alt is released. I just want Grave to work the same way. And it does, normally, if used by itself. It's just this transition between Alt+Tab and Alt+Grave which results in an immediate action. To my mind that unexpected immediate action (while Alt is still held down) is what is unpredictable based on the general behavior of either shortcut separately, while Alt is held down. 

> Re. §4: Okay, this no longer being weird with the script resolves my
> confusion.

*thumbs up emoji*

Re. §2: I was not talking about activation and the tab-grave transition issue, but raising and the singling out a window issue. If I understood you correctly, you want to be able break the pattern of raising all windows of an application together by activating a single window of an application with Alt+Grave. That's the inconsistency I'm questioning.

(In reply to Natalie Clarius from comment #12)
> Re. §2: I was not talking about activation and the tab-grave transition
> issue, but raising and the singling out a window issue. If I understood you
> correctly, you want to be able break the pattern of raising all windows of
> an application together by activating a single window of an application with
> Alt+Grave. That's the inconsistency I'm questioning.

Ah. But I don't see it as inconsistent. If you don't bother to switch to Alt+Graving, all windows are always kept together in GNOME. But if you do take the extra step of moving to Alt+Grave in the middle of Alt+Tabbing then the GNOME devs decided, "Oh, I guess the user just wants a single window this time." It's a hybrid mode that takes the best of both macOS app switching and Linux/Windows window switching. Even in macOS, you can do the right-click context menu or direct click method. But that means you have to take an extra, unusual step to make it happen. If you stick to Cmd+Tab or clicking on the whole Dock icon in macOS, and macOS sticks to keeping all the app windows together. No problem in either case. But there is the flexibility to just grab a single window if/when you really need to. 

Think of a situation where you might want to just see a single Dolphin window to be able to drag a file onto a Firefox window. If you have several Dolphin windows open and spread all over the screen, they may obscure the browser window and make the drag-and-drop action difficult if you bring the whole group forward in front of the browser window. This is one of the drawbacks of grouping application windows. On rare occasions you simple _don't_ want them all together. 

I escape the grouped-windows model using one of these methods probably much less than 5% of the time, maybe as little as 1%, but when I do I appreciate that it exists as an option. It's just not something I've ever thought of as being difficult or confusing to the overall issue of keeping app windows together 99% of the time. Simpler task switching, until I need to do something very specific, then I have to make slightly more effort. I see it all as very logical and consistent. 

Although, macOS is the only environment that has the consistency to keep you "inside" that same application if you happen to close the "isolated" window. In that limited sense, GNOME can produce a bit of inconsistency as it dumps you into a different app. But when you isolated a window and then wanted to close it, quite often that meant you wanted to switch back to a different app anyway, so this hasn't caused me too much of a problem when moving between macOS and GNOME. A little, but not too much. Nothing like the complete lack of app-based switching. 

I submitted a new bug about the unexpected window activation when transitioning to Alt+Grave. Tried to be as clear as possible with the instructions, so hopefully others can see it the way I see it. But I'm expecting to see a lot of confusion and "Meh?" responses. It's not exactly a showstopper bug. 

https://bugs.kde.org/show_bug.cgi?id=454413