GNOME Bugzilla – Bug 635527
Fast workspace / windows switching
Last modified: 2012-09-06 21:47:36 UTC
In our mailing list, people have been asking for taskbars for ages, but what they really wanted is a fast way to switch windows. Windows need to be switched in various cases: - when an application has more than one window (eg. gimp) - when your task (workspace) involve more than one application (eg. emacs and gnome-terminal/jhbuild, evince and oo-writer, gnucash and oo-calc) - when your task involve more than one application, and an application is shared with an other task, in a different workspace (a firefox tab, that is) - when you pause your current task (which you have not completed) for a small subtask (mail notification, chat window, long background task, change playing song...) - when you have finished your current task and want to start a new one Case one should be fixed by the application (potentially with some addition to mutter). Basically, tool windows should not overlap. Case four is perfectly fit for the old overview, in grid mode: you close your app, open the overview, look rapidly at outstanding issues, then pick a new one (or pick your favorite time tracker app). The new one on the other hand is horrible for this case: you need to scroll linearly all workspaces (O(n), with a big constant in front, caused by animation), then mentally sort from the most important task to the least, than search linearly again. Case two and three are instead not tackled at all, and this because they involve fast switching between windows that are not visible (two) and between different workspace (three). The old overview, with some habit, can address case three, as the combination of the app well and the grid view allowed to quickly focus a specific window. The new one cannot: right-clicking an app from a different workspace will leave you with an empty desktop, getting no clue on what window you are interested. Also, it requires you to think in terms of applications rather than documents. How do I know that "Document Viewer" is Evince, "Chat" is Empathy, "Mail" is Evolution and "Music" is Rhythmbox (or worse Banshee)? Both solutions still slow down your work, as they require roughly the same amount of time as case four, except that are done much more often. Overtime, the notification system will improve some of the use cases, though. Finally, none of current gnome-shell solutions can address case two. I'm not saying that we need a taskbar, but whatever the idea, we need something that is not covered by maximized apps (either by affecting the struts or by overlaying the workspace). Even in a 1400x900 desktop, a tiling window manager is unusable with anything more than 80x24 xterm. I hope that this can foster a productive discussion, ending up with a concrete proposal blessed by designers, rather than closing this as NOTABUG.
(In reply to comment #0) > - when your task (workspace) involve more than one application (eg. emacs and > gnome-terminal/jhbuild, evince and oo-writer, gnucash and oo-calc) I think this is the only case where the Shell doesn't provide an optimal experience. Other cases can be fixed by using more the messaging bar, and the overview solves other issues. > Finally, none of current gnome-shell solutions can address [tihs] case. I'm not > saying that we need a taskbar, but whatever the idea, we need something that is > not covered by maximized apps (either by affecting the struts or by overlaying > the workspace). Even in a 1400x900 desktop, a tiling window manager is unusable > with anything more than 80x24 xterm. It seems to me the use case where the Shell is when you need to go back and forth from one window to another, or between two windows. I'm often reading one or two PDFs, and writing notes in a text document. For this, I've started using intensively Alt+Tab, but I feel like this is merely a way to palliate the lack of a better solution. Most users don't use Alt+Tab, they cannot discover this shortcut by themselves, and they're not supposed to. (Plus, currently, switching between two PDFs and another window is a pain, because the app-based switcher forces you to play with mouse or keyboard arrows to choose one of the PDFs.) I know this is only my personal experience, but I think this will be the same problem every time people need to use several windows for a task. It's not always the case, but in this area the Shell needs improvement. Maybe it could be smart enough to understand you're going to keep using these windows together again and again, and allow for an easy circulation between them? Should we advise people to group such apps in a separate workspace, and provide an Alt+Tab-like feature easy to discover with the mouse? I know asking for an old-school windows list may sound silly, but for this task moving the mouse to the hot corner and then down to the wanted window, this every 2 minutes, isn't efficient. Maybe we could kind of "reinvent" the window list idea to fix this.
Doesn't the tiling somewhat address the workflow issue of needing multiple windows at a time? Second, ALT + ` swaps between application windows when using ALT + TAB. Why is moving the mouse to the hot corner and then to the wanted window every couple of minutes less desirable than attempting to read a list of windows from a panel (with no visual feedback other than name/icon) and target it with the mouse every couple?
(In reply to comment #2) > Doesn't the tiling somewhat address the workflow issue of needing multiple > windows at a time? Second, ALT + ` swaps between application windows when using > ALT + TAB. There is no tiling, in workspace mode (that is, when working). And it wouldn't work anyway, because our screens are too small for a tiling window manager. Second, keyboard bindings are completely unrelated to this bug, we need something that is easily discoverable by new users and can be used with one hand only. (Plus, on my keyboard Alt+` is Alt+AltRigth+', and it is mapped to IBus by default) > > Why is moving the mouse to the hot corner and then to the wanted window every > couple of minutes less desirable than attempting to read a list of windows from > a panel (with no visual feedback other than name/icon) and target it with the > mouse every couple? Because when you go to Overview, all your windows move, in an almost random order (depends on their position on screen). As a lot of users pointed out in the mailing list, zooming is very visually expensive and should be used only when absolutely needed (that is, when you actually want an overview of your current tasks). When you know your destination, that is when it is part of your focus, you should jump to it instantaneously.
(In reply to comment #3) > There is no tiling, in workspace mode (that is, when working). And it wouldn't > work anyway, because our screens are too small for a tiling window manager. > Second, keyboard bindings are completely unrelated to this bug, we need > something that is easily discoverable by new users and can be used with one > hand only. (Plus, on my keyboard Alt+` is Alt+AltRigth+', and it is mapped to > IBus by default) > That's a better argument to make. No wheels are spinning yet though. Tiling though is available while you are within your current workspace, so assuming you've arranged your workspaces by task you can also tile your working windows side by side, which is what I was talking about. It addresses the case of needing immediate access to more than a single window. Granted this is not so great on 1024px wide (which is a potential size due to netbooks). > Because when you go to Overview, all your windows move, in an almost random > order (depends on their position on screen). > As a lot of users pointed out in the mailing list, zooming is very visually > expensive and should be used only when absolutely needed (that is, when you > actually want an overview of your current tasks). When you know your > destination, that is when it is part of your focus, you should jump to it > instantaneously. Part of it is that zooming doesn't really use all of the available real estate. The tiling/zoom should be smarter in that regard (separate issue). Additionally I would point out that unless you are frequently opening and closing windows in a workspace the positions of the thumbnails won't change.
(In reply to comment #4) > (In reply to comment #3) > > There is no tiling, in workspace mode (that is, when working). And it wouldn't > > work anyway, because our screens are too small for a tiling window manager. > > Second, keyboard bindings are completely unrelated to this bug, we need > > something that is easily discoverable by new users and can be used with one > > hand only. (Plus, on my keyboard Alt+` is Alt+AltRigth+', and it is mapped to > > IBus by default) > > > > That's a better argument to make. No wheels are spinning yet though. Tiling > though is available while you are within your current workspace, so assuming > you've arranged your workspaces by task you can also tile your working windows > side by side, which is what I was talking about. It addresses the case of > needing immediate access to more than a single window. Granted this is not so > great on 1024px wide (which is a potential size due to netbooks). Actually, tiling it not a solution even on 900x1400. And doesn't work fast with more than two windows. > > > Because when you go to Overview, all your windows move, in an almost random > > order (depends on their position on screen). > > As a lot of users pointed out in the mailing list, zooming is very visually > > expensive and should be used only when absolutely needed (that is, when you > > actually want an overview of your current tasks). When you know your > > destination, that is when it is part of your focus, you should jump to it > > instantaneously. > > Part of it is that zooming doesn't really use all of the available real estate. > The tiling/zoom should be smarter in that regard (separate issue). Additionally > I would point out that unless you are frequently opening and closing windows in > a workspace the positions of the thumbnails won't change. Zooming cannot use the available space (it would not be zooming, if windows were shown 1:1), as there would not be space for the rest of the Overview. Secondly, it does not matter if window will move always in the same way, they will move, going back and forth from the Overview, and this is hard to put up with when you have more than one / two windows in your workspace.
*** Bug 640624 has been marked as a duplicate of this bug. ***
With the current (linear) implementation when I want to switch to a certain workspace I have to go to the left edge and then all the way to the right to get the full linear workspace panel. Switching to a window is even worse since I have to figure out on which workspace a tiny window is. I'd rather have a "zoom" that chooses between single linear and grid layout.
I would even say tiling is not a perfect solution at 1600x1200. There's always the desire to see more information, and sometimes it's useful to see part of another app's window while the foreground is showing a lot of stuff. At 3200x1200 (2 monitors) it starts to be reasonable.
Old bug, old stuff.