Of what I propose here as solutions to the problem you pose, I actually prefer a fixed grid solution (1.2) allowing for bidimensional movement but blocking the direction of non-existent VDs (2.1), because it overlaps with what someone who wants to disable this automatic behavior would use; this could make things much simpler to code.
1. Automatic management of virtual desktops LAYOUTS
Okay, I think of two options:
- Dynamic virtual desktops also means dynamic virtual desktops layout.
- Dynamic virtual desktops organize in a fixed grid.
Keep in mind that we are talking of an optional automatic behavior: it is obvious that if someone prefers to have a fixed grid, it should be possiblemto disable an automatic mechanism.
Option 1: Dynamic layouts
For the option (1):
I think that at this point, if the automation is actually enabled, we just lose the capacity of moving vertically in the grid (as it actually is in the Overview), OR we don’t need to automatically create as much virtual desktops as needed to provide another row to the grid: you can move vertically but get blocked when you are in VD 1:2 and there’s no 2:2 VD because there’s no open window in 2:1.
This is because the grid actually emerges from a more intelligent disposition of what, due to the introduction of the Overview, is just a one dimensional array of virtual desktop.
Example
Let’s make an example. Right now we can only treat virtual desktops as elements in a row so that the Overview can visualize them. We have a 2x1 layout, because there’s a window in VD 1:1, so the VD 1:2 got created. Now we open a window in VD 1:2, a new VD gets created, which for the Overview is just 1:3 (because the Overview only works with 1:X dispositions), but in the grid view this becomes a 2:1 VD.
Let’s continue. You open a window in VD 2:1, a 2:2 VD gets created in the grid, which for the Overview is just 1:4. You open a window in 2:2, a new VD gets created: for the Overview is 1:5, while the grid reorganizes itself with three colums, so 1:1 stays there, 1:2 stays there, 2:1 becomes 1:3, 2:2 becomes 2:1 and the new VD is 2:2.
At this point, we don’t regain access to a bidimensional movement, as we treat VDs according to the one-dimensional layout of Overview, but at least we have a better layout for the grid view.
Option 2: fixed columns number
For the option (2):
Maybe this one is less caotich: let’s have a fixed number of columns in the grid, but continue to dynamically add VDs.
Example
With the same example: the fixed columns number is 3, you open a window un 1:2, 1:3 gets created; you open a window in 1:3, 2:1 gets created.
2. Bidimensional navigation in grid view
For both options, what about vertical movement in the grid? Three options:
- Movement in the direction of non-existent VDs is blocked.
- The user get redirected in the right-most VD in the row he tried to access.
- We ditch bidimensional navigation and we stay with the monodimensional navigation the Overview provides us with.
Allowing bidimensional movement
Maybe both the first two options work best with the fixed grid layout, as the user receive consistent feedback that the VD is to be expected there, but at this Moment is empty.
Universally coeherent monodimensional movement
The third option could mean simplifying things: did we lost bidimensional navigation? Yes, but we have consistent behaviour across Overview, grid view, touchpad gestures (as only left and right swipes actually navigate VDs) and keyboard shortcut virtual desktop navigation (as two shortcut to navigate forward and backward are pretty intuitive, like Alt+Tab and Alt+Shift+Tab).
Why keep trying
Thesr possibilities should cover the behavior of something that we are actually trying to reintroduce, such as grid layouts and navigation, with the addition of dynamic management.
If we can nail this, we might be one step ahead of what Gnome beautifully realized, that is a dynamic monodimensional overview.