Created attachment 197796 [details] [review]
altTab: Separate applications if they span multiple workspaces

Instead of selecting the window to use based on which one was used last,
potentially changing workspaces in the process, split them out like we
do for apps that are on other workspaces.

I agree something should be done about this.

How does shell currently decide which workspace in the switcher gets the icon when you have two windows of the same app on two different workspaces?

(In reply to comment #2)
> I agree something should be done about this.
> 
> How does shell currently decide which workspace in the switcher gets the icon
> when you have two windows of the same app on two different workspaces?

If there's at least one window in the current workspace, it's placed into the current workspace, regardless of whether the most recently used window (the one that the app will switch to) is in the current workspace.

I tried fixing it so that we'll place it into the workspace where the most recently used window was, but I found it didn't work well

(In reply to comment #0)
> The ideal solution is to show one app icon per workspace, clearly showing
> the user where his windows lie, and allowing the user to make a more reasonable
> estimate about which window he will pick.

That is not what the patch does - I'm not convinced that having one app icon per workspace is a good solution, but the behavior in the patch looks utterly confusing to me:

For instance with three workspaces, an application which has windows on workspaces 1 and 3 will be represented by a single icon (associated with two windows) when alt-tabbing from the second workspace, but by two icons (each associated with a single window) otherwise.

(Assuming that the alt-tab popup and the dash should behave consistently, the same behavior would be even worse in the dash, with icons being added/removed by switching workspaces)

(In reply to comment #4)
> (In reply to comment #0)
> > The ideal solution is to show one app icon per workspace, clearly showing
> > the user where his windows lie, and allowing the user to make a more reasonable
> > estimate about which window he will pick.

Er, yeah, that's not what I meant in the prose, of course

> For instance with three workspaces, an application which has windows on
> workspaces 1 and 3 will be represented by a single icon (associated with two
> windows) when alt-tabbing from the second workspace, but by two icons (each
> associated with a single window) otherwise.

Assuming that the user often uses alt-tab to go to other windows in the same workspace, that seems sane to me.

> (Assuming that the alt-tab popup and the dash should behave consistently, the
> same behavior would be even worse in the dash, with icons being added/removed
> by switching workspaces)

We don't have a workspace separator line, nor do we do any implicit ordering or grouping in the dash. We can change that, but I don't think the UI should change as you're changing workspaces. We intentionally cache the windows so that it won't change in the alt-tab case.

Taking a step back: is the separator line really important in the alt+tab switcher? It seems to me that is causes more problems than it solves.

I'd think that using a switcing shortcut, on which workspace applications are is not very important. If you do care about it a workspace switcher is more desirable (which we can do).

(In reply to comment #6)
> Taking a step back: is the separator line really important in the alt+tab
> switcher? It seems to me that is causes more problems than it solves.
> 
> I'd think that using a switcing shortcut, on which workspace applications are
> is not very important. If you do care about it a workspace switcher is more
> desirable (which we can do).

Of course it matters. If workspaces didn't matter, users wouldn't use them.

(In reply to comment #7)
> (In reply to comment #6)
> > Taking a step back: is the separator line really important in the alt+tab
> > switcher? It seems to me that is causes more problems than it solves.
> > 
> > I'd think that using a switcing shortcut, on which workspace applications are
> > is not very important. If you do care about it a workspace switcher is more
> > desirable (which we can do).
> 
> Of course it matters. If workspaces didn't matter, users wouldn't use them.

I'm not talking about workspaces as a concept, but about their presence in the alt+tab switcher.

(In reply to comment #5)
> (In reply to comment #4)
> > For instance with three workspaces, an application which has windows on
> > workspaces 1 and 3 will be represented by a single icon (associated with two
> > windows) when alt-tabbing from the second workspace, but by two icons (each
> > associated with a single window) otherwise.
> 
> Assuming that the user often uses alt-tab to go to other windows in the same
> workspace, that seems sane to me.

As long as windows are on the same workspace, the proposal does not make any difference to the current behavior? Anyway, I strongly disagree that changing workspaces has an affect on the number of applications / grouping in the popup. (Also note that this breaks alt-` when the application is "split").


> > (Assuming that the alt-tab popup and the dash should behave consistently, the
> > same behavior would be even worse in the dash, with icons being added/removed
> > by switching workspaces)
> 
> We don't have a workspace separator line, nor do we do any implicit ordering or
> grouping in the dash. We can change that, but I don't think the UI should
> change as you're changing workspaces. We intentionally cache the windows so
> that it won't change in the alt-tab case.

I don't think I've seen much less complains about workspace switches when clicking a dash item than about alt-tab. In general, I don't think introducing inconsistency by grouping strictly by application in one case and somehow by workspace in the other is a good move.


(In reply to comment #6)
> Taking a step back: is the separator line really important in the alt+tab
> switcher? It seems to me that is causes more problems than it solves.

Removing the separator sounds like something we should consider (and I use both workspaces and alt-tab).


> I'd think that using a switcing shortcut, on which workspace applications are
> is not very important. If you do care about it a workspace switcher is more
> desirable (which we can do).

See http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/workspace-switcher.png (slightly off-topic bike shedding: if we can come up with a nicer shortcut than ctrl-alt-arrows, I'm all for it)

(In reply to comment #8)
> I'm not talking about workspaces as a concept, but about their presence in the
> alt+tab switcher.
I'd rather make Alt+Tab switch between windows of a single workspace. That would make workspaces more useful, and you'd have a clear idea of what you're doing in each workspace. ATM, this is just plain confusing - I keep going to the wrong workspace because Alt+Tab moved me somewhere without me noticing.

(In reply to comment #9)
> As long as windows are on the same workspace, the proposal does not make any
> difference to the current behavior? Anyway, I strongly disagree that changing
> workspaces has an affect on the number of applications / grouping in the popup.

Did you mean "as long as all windows are on the same workspace"? Yes, this only changes the behavior when one application has windows on more than one workspace.

> (Also note that this breaks alt-` when the application is "split").

This is a point, but it seems fairly easy to change this so that it jumps between all windows of the same application between all app icons.

See the patches in bug #660367 as well, as they're related to the Alt-` behavior.

> > > (Assuming that the alt-tab popup and the dash should behave consistently, the
> > > same behavior would be even worse in the dash, with icons being added/removed
> > > by switching workspaces)
> > 
> > We don't have a workspace separator line, nor do we do any implicit ordering or
> > grouping in the dash. We can change that, but I don't think the UI should
> > change as you're changing workspaces. We intentionally cache the windows so
> > that it won't change in the alt-tab case.
> 
> I don't think I've seen much less complains about workspace switches when
> clicking a dash item than about alt-tab. In general, I don't think introducing
> inconsistency by grouping strictly by application in one case and somehow by
> workspace in the other is a good move.
>
> > Taking a step back: is the separator line really important in the alt+tab
> > switcher? It seems to me that is causes more problems than it solves.
> 
> Removing the separator sounds like something we should consider (and I use both
> workspaces and alt-tab).

Alt-Tab and the dash I see as separate use cases. People have been told that you use workspaces to keep yourself focused on one task, and the overview and dash are for switching between active tasks or making new tasks. It's a much poorer UI for switching between items in the same task.

This leaves Alt-Tab and Alt-` for switching applications within the same task, unless we want to introduce another new thing for switching between applications in the same task.
 
> > I'd think that using a switcing shortcut, on which workspace applications are
> > is not very important. If you do care about it a workspace switcher is more
> > desirable (which we can do).
> 
> See
> http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/workspace-switcher.png
> (slightly off-topic bike shedding: if we can come up with a nicer shortcut than
> ctrl-alt-arrows, I'm all for it)

(In reply to comment #10)
> (In reply to comment #8)
> > I'm not talking about workspaces as a concept, but about their presence in the
> > alt+tab switcher.
> I'd rather make Alt+Tab switch between windows of a single workspace. That
> would make workspaces more useful, and you'd have a clear idea of what you're
> doing in each workspace. ATM, this is just plain confusing - I keep going to
> the wrong workspace because Alt+Tab moved me somewhere without me noticing.

I feel the same way. So strongly, in fact, that I'm disappointed every time I try to use workspaces, and often go back to a one-workspace model. I'm trying to do task X, but the Shell keeps bouncing me to another random task Y where I didn't want to be.

> (In reply to comment #6)
> Removing the separator sounds like something we should consider (and I use both
> workspaces and alt-tab).

Same for me.

> > I'd think that using a switcing shortcut, on which workspace applications are
> > is not very important. If you do care about it a workspace switcher is more
> > desirable (which we can do).
> 
> See
> http://git.gnome.org/browse/gnome-shell-design/plain/mockups/static/workspace-switcher.png
> (slightly off-topic bike shedding: if we can come up with a nicer shortcut than
> ctrl-alt-arrows, I'm all for it)

That would be very nice and it would complement the alt+tab switcher sans separators. What about Super+Up/Down? or Super+Tab?

After a long, long discussion on #gnome-design, there was no clear resolution other than some basic proposals and clarification of how people use workspaces. I'll try to do a basic summary here, but feel free to correct me if I got something wrong. Most people there were very clearly in one of two camps:

 * Workspaces are just extra space in case the computer is getting cluttered. A situation where the alt-tab doesn't care about workspaces (remove the separator) would benefit this use csae.

 * Workspaces are contain logically related windows. These people want to focus on something and are using a workspace to "isolate" themselves from other unrelated things that may be running. These people would benefit from the alt-tab switching away from the currently active workspace as few as possible. Example: a "Development" workspace with the terminal and emacs. The user would favor switching between applications in the same workspace.

The first proposal by Hylke: add a new tool for switching windows and applications within a workspace. Not sure many people liked this: We would have six shortcuts for manipulating windows.

Two other proposals revolved around splitting the two functions of "workspaces" into separate tools. For lack of better terminology, workspaces as in the first usage are called "physical workspaces" and the latter usage are "window task groups".

All applications in a "physical workspace" are grouped together, regardless of where they occupy in the space. Switching between windows and 'window task groups" with alt-tab would work as it would in this patch.


Open questions:

 * How do "window task groups" connect with dynamic workspaces?

 * How do "window task groups" connect with "desktop contexts", as in bug #579747?

 * If I close an application and re-open it, does it retain its "window task group"?


There are some interesting colloraries and ideas that may be worth investigating with this approach:

 * Saving sets of applications as "window task groups" for easy launch

 * Solving the "Linus Terminal" problem by making the dash launch a new window if one doesn't exist in the current "window task group".

 * Automatically categorizing and placing apps in "window task groups" based on user-assigned roles.


A few UI proposals for connecting "window task groups" and "physical workspaces" in the UI:

 * Group a set of related windows in the overview and mark them as "window task group". A simple system of assigning a set of windows a specific color outline or ad-hoc label might work.

 * Treat all workspaces as "window task groups" by default, and allow linking together to two workspaces to create one "window task group" between the two physical workspaces. This could be accommodated in the workspace switcher by showing no gap between the two workspaces, keeping everything the same.

(In reply to comment #13)
> After a long, long discussion on #gnome-design, there was no clear resolution
> other than some basic proposals and clarification of how people use workspaces.
> I'll try to do a basic summary here, but feel free to correct me if I got
> something wrong. Most people there were very clearly in one of two camps:
Thanks for the summary!

>  * Workspaces are just extra space in case the computer is getting cluttered. A
> situation where the alt-tab doesn't care about workspaces (remove the
> separator) would benefit this use csae.
I really fail to see how workspaces constitute "extra space" at all, if they're not used to group windows by tasks. To me, the point of workspaces is grouping related windows so that Alt+Tab finds them easily, and the overview only shows related windows.

If you don't group windows by "task" on workspaces, what do you get (that's not only a rhetorical question)? Why would you care how deep the window stack on a workspace is, since you need to switch among the whole pool of open windows anyway? Sounds plain mysterious to me... ;-)

There's another reason why I consider duplicating application icons problematic: if I see two icons in the popup and switch to one of them, why will the "quit" action in the app menu close both?

So I think this patch has major implications for the overall design and we should be very cautious about adding anything in this direction. And to be honest, I think your use case would be much better served by a windows-per-workspace switcher as suggested in comment #10 (and it might indeed make sense to add something like that).

For Hylke and myself, I filed bug 661156 ;-)

(In reply to comment #15)
> There's another reason why I consider duplicating application icons
> problematic: if I see two icons in the popup and switch to one of them, why
> will the "quit" action in the app menu close both?

...

I'm quite sure anybody who uses workspaces will know how to deal with this, and knows that there's only one application. There's still only one icon in the dash.

Keep in mind that the problem here is that going to something *before* the separator can change your workspace based on the LUT, and that going to a specific window is harder. There can be specific cases where Alt-Tab twice in a row will send you to the wrong place.

The solution here is because of Alt-Tab has a separator. The Dash will still work as it did before.

> So I think this patch has major implications for the overall design and we
> should be very cautious about adding anything in this direction. And to be
> honest, I think your use case would be much better served by a
> windows-per-workspace switcher as suggested in comment #10 (and it might indeed
> make sense to add something like that).

Can we add this new switcher as Alt-Tab, like every other DE has? Perhaps make it switch windows globally in the same workspace, and make the logic that powers Alt-Tab in every other place? These rules:

  http://en.wikipedia.org/wiki/Alt-Tab#Precise_behavior

(In reply to comment #16)
> > So I think this patch has major implications for the overall design and we
> > should be very cautious about adding anything in this direction. And to be
> > honest, I think your use case would be much better served by a
> > windows-per-workspace switcher as suggested in comment #10 (and it might indeed
> > make sense to add something like that).
> 
> Can we add this new switcher as Alt-Tab, like every other DE has?

This is really a question for the designers. Personally I wouldn't have a problem to "move" the application-based switcher to another shortcut (provided that it is something relatively easy to hit like super-tab - no ctrl-alt-pgUp for me please).

*** Bug 662578 has been marked as a duplicate of this bug. ***

Oh my... Guys, there is no such thing as an "app". There are only windows. By creating this artificial distinction you find yourself solving problems that wouldn't even exist if you had only windows.

A few examples:

>If an application's windows spans multiple workspaces, selecting the 
>window could sometimes select another workspace, even if the 
>application is *clearly* on the left side of the "active workspace" 
>separator line.

See what you did there? If you just treat windows as windows, and only show current desktop's windows in Alt-Tab, then THERE IS NO CONFUSION.

Please realize that Alt-Tab switcher has no way of knowing what is an app and what is a window. This distinction you're trying to invent is based on processes and is clearly obsolete: there are web-based apps that run in different browser windows, then there are terminal-based apps. 

Please consider the proper behaviour:

1) Alt+Tab iterates over the list of WINDOWS on the current desktop

This makes everything simple and you don't end up in weird situations of sudden desktop flips or double-decked (!) Alt-tab switchers. 

Do you honestly believe you're making it simpler???

To re-iterate, I just want to compile a list of issues you have created. Please come up with at least one counter-argument.

The list of problems of not following the proper Gnome-2/XFCE model:

1) Desktop flips, when user is suddenly thrown into another desktop by accidently switching to the window which happens to be somewhere else.

2) Forcing people to watch themselves and trying to guess is it Alt+Tab or Alt+~ when all they want is to switch to a non-focused *window they're looking at!!!*

3) Giant.. I mean insanely giant Alt+Tab lists. Modern machines have so much RAM that people don't bother closing apps, so they end up with dozens of icons in Alt+Tab list.

4) Web apps, or terminal-based apps, or apps launched by the same VM like JVM/Squeak will be squeezed into the same "app" and users will have to try to guess "is it Alt+Tab or Alt+~" (related to #2)

How is this OK? What is achieved by adding these 4 problems? I.e. if such huge sacrifices in usability are made, I am curious to hear: what for?

Bug #650030, about opening a new window if there is no window of a given app in the current workspace, might be related to this bug.

Bug #650289 is also very much related to this one, but is more general.

My take is that workspaces really are a way to isolate a task from the others. So, in my opinion, alt-tab should only show the current workspace apps (or even windows, as Eugueny suggested). And clicking on a dash icon should never ever move you away from your workspace. Actually, maybe a simple rule could be that nothing except the workspcae switcher should ever move users from their current workspace. Else, workspaces become useless in that they don't help users focus on their current task.

We no longer consider workspaces in the application switcher, so I don't think it makes sense to leave this open.