Window switching problems and ideas

[Stanisław Pitucha <viraptor gmail com>]

Hi,
I'd like to list my problems, but it might be a bit pointless to join 
the shouting in the thread this came from. So here's my (hopefully) 
well-defined proposal.

On 18.12.2009 22:43, Owen Taylor wrote:
> More interesting things to discuss:
>
>   - In what cases does GNOME Shell work less well?

Window switching in two cases:
A: many desktops with few windows per desktop
B: many desktops with similar windows (grouping)
C: general continuity in window switching

Case A: What is different from the original gnome, is that in g-s with 
we lose orientation about what element is present where. Lets say we've 
got a browser and a terminal in desktop 1 and a couple of terminals in 
other desktops. I can have the terminals arranged in some specific way 
across the desktops, but when I use the window switcher, suddenly all 
terminals are pulled under one item which appears to be on the current 
desktop. That's distracting and I'm always able to distinguish between 
those windows - for example I can be logged in on the same host for 
different reasons on different desktops, but the windows will get to the 
same list and will not differ in any significant way.

Case B: In G-S my browser window group is usually called "File 
downloads", because that's the window which was opened as the latest.

Case C: Pressing alt-tab in a desktop with one window will select a 
window in another desktop. While typical window-switcher in other 
systems guarantees that you can press alt-tab, do some work and press 
alt-tab again to get to the same window, gnome-shell breaks this 
contract. You can find yourself in another desktop and pressing alt-tab 
again will select another app on that desktop, not the last app you were 
using.

>   - How could the GNOME Shell ideas be adapted and extended to
>     work better in those cases?

Case A:
If you group applications, never group them across many desktops. 
Allowing a separate group of terminals for each desktop would be 
helpful. I can't think of other applications that could use the same 
treatment, so maybe it should be an option for the user to decide - 
"group from all desktops" / "create a group per desktop". Or, see case B.

Case B:
It seems that G-S jumped on the bandwagon with the windows grouping. 
Window groups exists on MSW and OSX (correct me if I'm wrong, I don't 
have much exp. with macs) - they save space on the task/dock-bar, 
because there are no multiple desktops - there is not much more those 
systems can do, before they start stacking another layer of icons. Does 
G-S have to do that? G-S improves the multiple-desktops paradigm a lot - 
do we need grouping to do with that at all?

Case C:
Prevent accidental change of desktops. Assuming that the previous 
task-switcher contract is already broken, don't allow to switch desktops 
with the first alt-tab action.

Example 1:
- desktop 1: firefox (active), desktop 2: pidgin
After alt-tab, the window switcher appears, but firefox is swill 
selected. Next alt-tab selects pidgin in desktop 2.

Example 2:
- desktop 1: firefox (active), evince, desktop 2: pidgin
After alt-tab, the window switcher appears, evince is selected. Next 
alt-tab selects pidgin in desktop 2.

>   - What alternate ideas would address the issues that the GNOME shell
>     design document starts from? how would you evolve the GNOME shell
>     in those directions?

I'll try to describe the behaviour, because I can't draw :) How about 
using a window switcher which is presented as a stripe fading on the 
left and right if it takes too much space. Group the windows by 
background shading, but don't collapse them. Put a bar between each 
desktop (like the current "this|others" separator) and don't collapse 
applications across desktops. If there is space, include the right/left 
desktop applications on the same screen. If the whole list with every 
desktop doesn't fit on one screen, make the switcher work like a ring 
where desktop 1 follows desktop N on the right.