Unity needs a way to switch (tab) between windows on current workspace

[Justyn Butler]

The new Unity alt-tab switcher aggregates windows from all workspaces and groups them by application.
This replaces the old default, which would switch through windows on the current workspace only.

The omission of the ability to switch between windows only on the current workspace removes some core functionality of workspaces.
It creates impracticalities for using workspaces in a keyboard-driven workflow. I will illustrate these below.

For this discussion I presume that the user has more than one window on some or all workspaces, since otherwise much of the point of workspaces becomes moot.

Previous keyboard driven alt-tab workflow:
User moves to relevant workspace with ctrl-alt-[arrow]. They alt-tab to select the desired window on that workspace.
If the user has grouped windows together on a workspace because they want to use them together, for example a word processor and some open PDFs, switching quickly between them while typing is straightforward and fast. If they tab to the wrong window it will gain focus and they will quickly tab to the new one.

Keyboard driven workflow using new alt-tab:
Ctrl-alt-[arrow] becomes redundant, since alt-tab will take the user to whichever workspace the application is on, so the user is no longer directly using the spacial workspace concept. Alt-tab may take longer to navigate because it contains all windows on all workspaces.
Switching between windows intentionally grouped onto one workspace becomes more laborious because there are many erroneous windows. Furthermore, if the user accidentally selects the wrong window it can be quite dizzying since they are unexpectedly whisked away to another workspace, then back again when they select the right one.

This raises the question: why use the spacial concept of workspaces at all, when the window must be selected from a single long list anyway?

The solution is to add a new shortcut for cycling between windows on a single workspace (and without grouping them by application). That is, the old behavior but on a new key combination.

I propose that the most elegant keybinding for this would be ctrl-alt-tab, because this links well with the keys for moving between workspaces, enabling a smooth flow for selecting a workspace and then a window on it.

Proposed ctrl-alt-tab workflow:
User moves to relevant workspace with ctrl-alt-[arrow]. Continuing to hold ctr-alt down, they may use tab to select the desired window on that workspace.
Moving between windows intentionally grouped onto a workspace is again fast and efficient.

--------------------------------------------

Desired Solution:

- In 12.04, by default Alt-tab should only switch between windows on the currently visible workspace (or workspaces in the case of multiple monitors).

[Jason Smith (jassmith)]

Open ccsm -> Unity Plugin -> Switcher -> check the box that makes the switcher workspace aware (changes sorting order)

[Justyn Butler (justyn)]

That is worth knowing, thanks.

However I don't think it fundamentally solves the issue. It also doesn't address the problem caused by multiple windows of the same application being on a workspace.

[Jake (jmiheve)]

I agree with the idea, but rather than putting the old behaviour on a new keycombo I would suggest using Alt+Tab for switching within the current workspace and Ctrl+Alt+Tab for switching among all workspaces. The 2-key combination staying on one workspace is already expected behaviour, and it is simpler and easier to use and the simpler combo should be used with the most likely workflow. Also, since Ctrl+Alt+[arrow] is already used for switching workspaces it keeps the Ctrl+Alt+[$Key] 'meme' a common for working with multiple workspaces.

The same arrangement could be used with the new Alt+[`] combo for multiple instances of the same application: Alt+[`] would restrict itself to the current workspace (e.g., with multiple terminal windows on more than one workspace it would only show those on the current workspace) and Ctrl+Alt+[`] would show all instances of the same application from all workspaces.

The current method certainly can frequently disrupt a person's workflow, especially if they have multiple similar projects running at once and kept separate by using different workspaces for each.

[Justyn Butler (justyn)]

I suspect that part of the problem is that Alt-Tab is a well known key combination from other operating systems, so it is the one new users are most likely to discover first, before Ctrl-Alt-Tab.

From that perspective it makes sense to present the users with all applications with Alt-Tab, as this avoids them "losing" windows due to them being on other workspaces.

[Gnurfos (gnurfos)]

As long as it is configurable, any default would be fine !

[Justyn Butler (justyn)]

On the subject of whether the current-workspace-only application switcher should work in a similar fashion to the new Unity switcher, I would say there is good reason not to.

The new Unity switcher shows icons for each application, and if using Alt-` it will show a preview of the window. This is useful for locating a particular window when there are many and the user doesn't know/care where they are. It is not possible for the switcher to highlight the window itself because it may be on a different workspace.

However when dealing with windows only on the current workspace this approach would be suboptimal.
When a user has positioned windows on a workspace they are aware of where they are spatially, and so highlighting the window itself, as the traditional application switcher does, is more intuitive.

[Justyn Butler (justyn)]

I think the solution could be this simple:

Unity could ship with the Compiz Application Switcher enabled but the keybindings for next window/prev window changed to Ctrl-Alt-Tab and Shift-Ctrl-Alt-Tab.

I think there is a strong case for doing this by default from a usability perspective, and doing so should help assuage the frustrations of the users who are sure to be put out by the Alt-Tab change.

(A minor note: Compiz currently doesn't allow moving from ctrl-alt-[arrow] to ctrl-alt-tab without releasing ctrl-alt first, but this could be fixed later).

[Jason Smith (jassmith)]

Okay wow, there is a lot of stuff being written here...

So here are my points, in no particular order:

0) I have perhaps one of the most complicated use cases of alt-tab anyone has imagined. I do programming, visual design, and 3d modelling simultaneously, plus web browsing, chatting and email. Usually I have between 10 and 15 applications open at any moment, and maybe twice as many windows. I make heavy usage of workspaces (9 of them) and even heavier usage of alt-tab. That said, it took me about a week of trying to get used to the new alt-tabbing setup, but after I did, I find it a much less frustrating experience. The reason for this has not to do with how long it takes me to use alt-tab (I think my measurements were that I spend like 1.2x times longer alt-tabbing now) but rather I never feel "lost" inside my alt-tab anymore. I can always see the whole picture, so I never feel like I am hitting tab waiting for the right thing to happen. The entire experience feels much more predictable and easier to plan your workflow. I think thats what sells me on this scheme, I feel like I have a birds eye view of whats happening, not a reactive view where I hit tab to see if the right window highlights on my desktop.

1) Unity is application based, not window based. We try to enable some window based management features, but not to the detriment of the application based view. You're going to have to drink that kool-aid sooner or later if you want to be happy.

2) Obviously if we did a special mode for alt-tab that was applications on the current workspace only, we would not change the current look and feel. This would be entirely inconsistent and make people wonder why the interfaces are different. If you notice in the latest unity, the previews are quite large in the switcher (up to 400px tall). The proposed solution of highlighting the actual window may get confusing when windows are partly offscreen (or mostly offscreen).

The bias option I suggested before should fix the primary reasons people want a workspace limited switcher. A quick alt-tab press will, for example, focus your previously focused window on the current workspace. I don't pretend this means it works keypress for keypress identically to the previous switchers, it doesn't, it never was intended to.

[Jake (jmiheve)]

In response to Jason:

0) It may work for you, but you're starting out by mentioning that you're an unusual (or at least an extreme) use case. I know that I am finding it jarring and disruptive to my work flow, because I organize my tasks by workspace - when I'm working in one, I don't want to be interrupted by accidentally going to another that's not related or is only tangentially related. I'm finding it very difficult to work with, and very annoying.

1) "Unity is application based, not window based. We try to enable some window based management features, but not to the detriment of the application based view."

Unfortunately, this is one area that focusing on the application-based view seems to be to the detriment of usability - which should *always* take priority. I'm leery of the whole application based view to begin with, because the general user sees *windows*, not applications. The average person will see two Firefox windows open, not Firefox with two windows.

"You're going to have to drink that kool-aid sooner or later if you want to be happy."

That attitude is what is pissing off a significant portion of the current user-base, just FYI.

2) I'm not really sure what you're getting at with this. I've been trying gnome-shell for the last couple of days, so maybe tonight I'll log in with unity and refresh my memory.

I haven't tried the bias option you mentioned, but I will. I don't think it's really what people are wanting, though. I know when I'm working on one workspace, I don't want to be bothered with the others unless I specifically ask to be. It sounds like this will still show windows on other workspaces in the same view.

The workspace paradigm is an excellent tool for task organization, as you noted. Just as an example, a common use case for me would be balancing my checkbook and paying bills on Workspace (WS) 1 (KMyMoney, LibreOffice Calc, Gedit, Firefox), and writing a document on WS2 (LO Writer, Gedit, Firefox, PDFs). When I'm working on the checkbook, I don't want to see anything not having to do with that task, and I especially don't want to have to sort through the various windows whose applications are common to both workspaces (i.e., Firefox, Gedit, etc.). The idea is similar to why the MS ribbon is such a horrible idea - if I have to stop to think "Is it this one or that one I'm working with right now?", then my workflow has been disrupted along with my focus, and it just slows me down and introduces greater potential for mistakes. The application-based view of Unity has interfered with the task-management view of the workspaces.

[Jason Smith (jassmith)]

This would be a great series of comments to raise on the ayatana design mailing list :)

[Justyn Butler (justyn)]

I think perhaps some comments went a little off track.

Lets be clear that we are essentially talking about two different use cases:
1) Generally finding an open application
2) Trying to change window focus, having grouped multiple windows on your workspace, when you are already on the workspace you want.

Right now with the new switcher the applications are abstracted as icons. This is good for the first case, a "high-level" overview of all applications, as you say.

But for the second case it is clearly deficient. The Compiz Application Switcher actually highlights each window itself as you tab through them.
So you're on a workspace with multiple windows. You look at the window you want to type in - now you need to change the window focus so that you can type in it. You want to tab through the visible windows, and you want the window itself to be highlighted, not an abstracted icon.

I'm not suggesting a change to the design here, since this wouldn't involve any change to the new switcher.

[Danillo (danillo)]

I tried the biased alt-tab, but 'm having a really hard time with it. I still don't get it.

I got two Firefox windows open in one workspace, and one gmusicbrowser open in another. I ctrl-alt to the gmusicbrowser workspace in order to change the music to another artist's, then I ctrl-alt back to the Firefox workspace. When I alt-tab to try to go to the other FIrefox window in this workspace, I'm taken back to gmusicbrowser's workspace. I gotta spend a lot of time looking at the switcher to go to where I want.

I've always handled the application-based launcher wonderfully, but this alt-tab is confusing me a lot. I can't get around it. It's like the workspaces don't matter, like they were inexistent.

In addition to that bias option, I would really appreciate a ticking box to lock alt-tab to the current workspace.

[Jake (jmiheve)]

Testing it now in Unity, and I will confirm my initial assessment that it is absolutely horrid.

WS1 - Firefox (maximized), Gedit, and a terminal
WS2 - Gedit and two terminals

Both instances of Gedit have different (but similar style) documents open, two of the terminals have different man files open, and the third terminal has a directory listing. Firefox is Firefox. :P

Using Unity's switcher, I have to stop and read the terminal previews or the Gedit previews to see if I'm selecting the one on the WS that I'm actually working with. It's doable for me on my monitor (17", 1400 x 900) but my Dad probably wouldn't be able to do it. Even with only two Gedit windows open, I'm often finding myself on the wrong WS when switching to one from another application. On an even slightly smaller monitor it would be questionable, and on a notebook I might not be able to do it at all. A way to limit the switcher to the current workspace really is essential.

My current personal solution while I'm in Unity is to use the shift switcher and scale plugins in Compiz. Both can be easily set with keybindings for both the current workspace and all workspaces, and give significantly larger previews. Unfortunately, that workaround won't work for people having issues with Compiz. (On a side note, the Compiz shift switcher isn't showing window titles under the preview, even though I have the option selected. I may hunt down/submit a bug report on that later.)

Justyn is correct - the current implementation for his case #2 is terribly deficient. As much as Unity is trying to be application-based, when it comes down to it, people actually do and arrange their work in windows, not applications, because windows are the visual and tangible medium that is available while applications are (to the 'average' user, at least) a more general concept.

[Alfredo Buttari (alfredo-buttari)]

I have to agree on this one. Desktops are meant to keep things separate while the new switcher puts them all together again. This is totally counterintuitive and in my opinion a severe usability regression. In my specific case, I have several terminals open in every workspace but I know exactly on which desktop is each of them (they're kind of logically grouped by activities). So with the old behavior the terminal I want is only a few clicks away while with the new behavior I have to:

1) click alt+tab (as was pointed out before, it doesn't make sense anymore to move to the right workspace)
2) use alt+left or alt+right until the terminals group is selected
3) click alt+down to ungroup the terminals (or wait that it happens automatically)
4) move closer to the screen in order to figure out which terminal contains what (this is really painful: how am I supposed to recognize a terminal from its thumbnail???)
5) navigate to it using, again alt+left or alt+right

all this takes a whole lot of time and clicks.

So, this problem combined with

1) the fact that I have no way of knowing in which desktop I am (unless I type some other shortcut and wait for the related animation to complete)
2) the fact that I have no way of knowing how many and which windows I have open on the desktop I'm in (unless, again, I type some other shortcut and wait for the related animation to complete)

drops considerably my productivity.

BTW
is this the right place to discuss such things? bugs are normally intended as implementation mistakes but here the design itself is wrong (always IMHO).

[Justyn Butler (justyn)]

Apparently the Ayatana mailing list is the place to discuss these things. I started a thread about this issue here:

https://lists.launchpad.net/ayatana/msg06678.html

In my view you could boil down the problem to there being two different possible goals when the user activates the switcher:
1) Locating a currently running application
2) Changing window focus

The new switcher improves on (1) but to the detriment of (2).

Something like the Compiz Application Switcher plugin, which highlights the window itself as you tab (and is restricted to the current workspace only), is optimum for (2). I think it should be enabled by default with a new keybinding, like ctrl-alt-tab.

[Janne Moren (jan-moren-gmail)]

The main problem from my point of view really is that it switches the workspace for me. Like some other people on the thread I organize my work be workspace and getting pulled from one space to another is very jarring and disruptive.

[Piotr Wiktorowski (varietyfair)]

affects me to this is one of the things i hate the most in OSX and I'm not happy to see it coming to Ubuntu

[Bryan Larsen (bryan-larsen)]

There seems to be two separate things people are asking for:

1) add a new keybinding: Next Window (group), which only switches within the current workspace. Either map it to super-tab or ctrl-alt-tab or even leave it unbound and require people who want it to use ccsm.

2) add the new keybinding Next Window (group) and map it to alt-tab and map the current behaviour to super-tab or ctrl-alt-tab.

I don't understand the opposition to #1. It'll make a bunch of people happy and doesn't affect anybody else. Most other switchers have this binding available, but I think the Unity switcher is nicer than the others, so I'd prefer to use it. I would think that a reasonable response to #1 if you don't want to do it would be "send me a patch".

#2 is a much larger design decision to be taken at a different level. With the release of oneiric with the current behaviour, I suspect that this option is completely off the table.

[neilyalowitz (neilyalowitz)]

The "bias alt-tab sorting to prefer windows on the current viewport" helps, but it does not overcome the problem of Unity constantly aggregating/collapsing instances of an application into one icon (and regardless of which Workspace is lives on).

I may have three terminals open in Workspace 1, and three more in Workspace 2, but according to the alt-tab menu they are all the same... and when I alt-tab and expand the Application "group," the order of the icons will change as well. It's absolutely impossible to keep them straight. The issue is the same with the sidebar Unity Launcher... all six instances are one icon. This is aggravated by the fact that there is no "taskbar" anymore (which was along the bottom of the screen in pre-Unity) to note which instances are part of Workspace 1 or Workspace 2.

I understand the earlier comment remarking on how this is a "bird's eye view" but expecting everyone to have the same approach is too much. I'm constantly being told how I need to change my behavior to match Unity, and it's disappointing. You're asking me to un-learn years of muscle memory here!

A more configurable option here would be ideal:

* option to disable aggregating instances according to Application

[manny (estelar57)]

something much more complete than workspaces would be in the style of KDE4's activities or firefox's "panorama" but for ubuntu:

http://www.techdrivein.com/2011/03/how-about-firefox-4s-panorama-like.html

http://www.kde.org/announcements/plasma-active-one/

[Martin Albisetti (beuno)]

This bug has essentially made alt+tab useless for me in Oneiric, and this is wide-spread if you take a quick look at IRC, google+ and twitter.
It's understandable that this is not a core use case for "consumers", but it's critical for power users.

There has been by no means any research or arguments presented to mark this bug as invalid.

[Martin Albisetti (beuno)]

Setting back to new and as "Critical" since it's a major regression.

[Justyn Butler (justyn)]

There is some forum discussion about whether there could be a fundamental inconsistency in Unity between the design of workspace-agnostic elements like the new switcher and the continued use of multiple workspaces:

http://ubuntuforums.org/showthread.php?p=11371709

[Justyn Butler (justyn)]

Oops, previous link went straight to my reply in the thread about the use of workspaces in the current Unity design. Apologies.

This link is to the top of that thread:
http://ubuntuforums.org/showthread.php?t=1862661

[Mark Shuttleworth (sabdfl)]

The Forums thread at http://ubuntuforums.org/showthread.php?t=1862661 is
essentially correct - the relationship between Workspaces and the rest
of Unity is inconsistent. That's simply because we have not yet got to
implement Workspaces the way we'd like, and what's currently shipping is
the Compiz Workspaces plugin bolted alongside the rest of Unity.

Some pieces are already in place, for example, the Launcher
distinguishes between apps running on this workspace, and other workspaces.

Among many other changes we'd like to see in Workspaces:

 * Alt-TAB should only switch between apps on the current Workspace
 * Clicking on a Launcher icon for an app running elsewhere but not in
the current Workspace, which knows how to have multiple windows and
create new windows, should create a new window in the current Workspace

I've cc'd John Lea and Stewart Wilson who are the right folk to lead
further discussion.

Mark

[Justyn Butler (justyn)]

That is excellent news, it clears up a lot of confusion.

I hope the changes will be ready for 12.04 LTS, since the current implementation is rather frustrating.

[Dirk Mcbratney (djmcbratney)]

Yes, definitely. I look forward to seeing this put into place, and it would be awesome to have it in the LTS.

[Mark Hayes (3y9m2vc-llwd-fkzsxrq)]

I agree with the last two posters. I very much look forward to the change. Thank you for working on it.

Because I can't currently switch between windows easily within a workspace, it makes workspaces much less useful. I create lots of terminal windows and I need to put them in groups and only work in one group at a time.

[Jason Smith (jassmith)]

Alt-tab switcher now has an option to make it workspace aware as requested. It will only show applications and windows on the current viewport when this mode is enabled. This will land in 12.04, however is in trunk today.

[Daniele Varrazzo (daniele-varrazzo)]

Does it mean that we will have to live with the broken tabbing policy for 6 months?

[Alfredo Buttari (alfredo-buttari)]

Daniele,
one easy workaround for this problem is to disable the "Viewport Switcher" in CompizConfig and enable the "Application Switcher" instead. This restores the old alt+tab behavior although it loses some feature (for example I'm not able to jump directly to ine desktop anymore).

regards
alfredo

[katmagic (the-magical-kat)]

This fix needs to be backported. This _regression_ ruins workspaces for several people I know who are not technically knowledgeable enough to compile from source. For one, multiple desktops are the primary reason they switched to Ubuntu.

[Andrej Mosi (mosibiz)]

In 11.10, I can not use the ccsm and about:config unity to turn on the "Bias alt-tab sorting to prefer windows on current workspace". The option is checked to YES. Even gconf-editor is showing the option as enabled.

Is there any other way of changing this option? Where should one look for remedy if the option has no effect whatsoever?

On top of that, ccsm crashes miserably when trying to manage profiles, damaging the gconf configuration unrecoverably. This is some UTF8 encoding error in python when trying to read the unity profile. Is it just my installation or do you have the same problem?

[Jon-o Addleman (jaddle)]

I would also like to see this fix backported if possible. The compiz workaround is better than nothing, but as others have mentioned, only works on compiz-friendly systems. It's a major regression in one of the most frequently used parts of the UI. Even a fix in a PPA would be welcome, though most would never see it.

Glad to see that it has been fixed in any case, even if we can't actually see it yet.

[Marco Lackovic (marco-lackovic)]

I agree the current ALT+TAB behavior is is totally counterintuitive and a usability regression.

Quoting Gnurfos from ubuntuforums, "Users don't assign windows randomly to workspaces, they rather dedicate workspaces to their 'meta-tasks'. And then they have 2 use cases:
- switch between meta-tasks, in which case they switch workspace
- stay on the same task but switch windows (inside this task)"

I don't see any other reason why users should put applications on different workspaces if not to be able to fast switch among applications of a meta-task and put the other applications aside so that they don't interfere with the current work.

For these reasons I believe Alt-TAB, by default, should only switch between applications of the current Workspace. I hope this fix will be backported.

[John Lea (johnlea)]

@marco-lackovic; In 12.04, by default Alt-tab will only switch between windows on the currently visible workspace(s).

[Ryan Graham (rxgraham)]

I agree with the loss of productivity here, and am glad this will make it into 12.04. I hope to see a backport on this though.

[Callum Macdonald (chmac)]

I've recently installed 12.04 alpha and the default behaviour was to alt-tab between all applications (rather than windows) across all viewports. Hopefully this change is incorporated before the final release.

[Jason Smith (jassmith)]

Checking the box now exactly matches the described behavior.

[Launchpad Janitor (janitor)]

This bug was fixed in the package unity - 5.2.0-0ubuntu1

---------------
unity (5.2.0-0ubuntu1) precise; urgency=low

  * New upstream release.
    - Unity needs a way to switch (tab) between windows on current workspace
      (LP: #863399)
    - compiz crashed with SIGSEGV in BamfLauncherIcon::NameForWindow()
      (LP: #865840)
    - Gradual degradation in desktop performance. (LP: #888039)
    - compiz (unity) crashes with SIGSEGV when a window is minimized.
      (LP: #918329)
    - FavoriteStore external change support (LP: #681503)
    - Launcher - Make Launcher left of screen reveal more responsive and less
      prone to false positives (LP: #765819)
    - Window auto-maximise functionality should be disabled on monitors with a
      resolution above 1024 x 600 (LP: #797808)
    - Dash: very high latency responding to input (LP: #828582)
    - Dash - Behaviour of the 'All' button in the Dash filters broken in
      several ways (LP: #841864)
    - alt-tab - The app title in the top left of the top bar should change as
      the alt-tab focus changes (LP: #855516)
    - Keyboard shortcut - Add keyboard shortcut hint overlay that is displayed
      when a user presses and holds the Super key (LP: #855532)
    - Unity crashes when started in an environment without utouch support
      (LP: #860707)
    - Dash - Remove Dash Home shortcut icons (LP: #885738)
    - Dash - Most Frequently Used apps change to Recently Used, without
      Launcher favorites (LP: #893214)
    - Should have a launcher on every monitor (LP: #915944)
    - Launcher autohide behaviour on multi-monitor (LP: #915946)
    - the unity wrapper should kill compiz before restarting it (LP: #919132)
    - Launcher - Implement workspace/launcher cross interactions (LP: #690143)
    - Application icons should only display windows from the current workspace
      in the window spread (LP: #689733)
    - Notification area ("system tray") missing when using dual monitors of
      different sizes, with their bottoms aligned (LP: #778256)
    - Clicking Nautilus launcher icon fails to open a Nautilus file explorer
      window when copying a file and all other Nautilus windows are closed /
      bamf should skip the taskbar (LP: #784804)
    - Dash - the search box is not aligned correctly relative to the Launcher
      BFB button (LP: #838904)
    - Dash - A expand/collapse arrow is missing from all the filter category
      headers (LP: #841870)
    - Dash - the filter buttons should not have a mouse over state
      (LP: #838901)
    - Dash - the "Filter results" text is the wrong size, wrong font weight,
      and aligned incorrectly in both the vertical and horizontal axis
      (LP: #863240)
    - Add SUPER+TAB switching mode that enables the user to switch
      applications via the Launcher (LP: #891620)
    - Software Centre - automatically add app icon to launcher (LP: #761851)
    - Compiz add transparency to titlebar along with the panel (LP: #912682)
    - The search box is too opaque and dark (LP: #913717)
    - Dash - Make statefulness of Dash Home and Dash Lenses consistent
      (LP: #914759)
    - Unity 5.0: "All" button for filters render as "..." (LP: #91...

[Matt Price (matt-price)]

I doubt this is really the right place for this comment but hoping someone can point me to the proper location. Just switched to precise and the ctrl-alt-tab is a major improvement on the previous behaviour -- thank you so much for implementing it. However, this bug has made me awre of kde activities, which seem to me an even better solutin to my issues. Are there plans to implement something closer to activities, and/or are there suggestions for simulating activites in the current precise environment?
thanks!

[Mark Shuttleworth (sabdfl)]

Workspaces?