Automatic virtual desktops management

This topic follows something of what has been said in Having two virtual desktops by deafult would improve visibility of virtual desktop feature, unfortunately going out of scope.

What some of us propose is to introduce in Plasma an automatic way of managing virtual desktops, keeping the possibility to disable the automation in order to let people use their grid layout.
The proposal is composed of two aspects:

  1. Replicate the functioning of the Temporary Virtual Destops and dynamic_workspaces scripts, that is: creating a new virtual desktop when the previous get filled with at least one window; removing any empty virtual desktop.
  2. Automatically arrange any number of virtual desktops in a grid, instead of horizontally, so that the grid view always has a comfortable layout.

At least for point (1), this is the same behaviour for Gnome and I find it very useful: given that if you want to have a fixed grid of desktops you should be able to just disable this automation, this management of virtual desktops would create a great basic workflow, improving visibility of the virtual desktops feature and also ensuring that the default number of virtual desktops at boot is 2, both things suggested in Having two virtual desktops by default would improve visibility of virtual desktop feature by @amar and @TDuffinNTU.

Point (2) would in some way regain a proper layout for virtual desktops, after that the introduction of the Overview somewhat messed with it. We could have virtual desktops automatically arrange by 2x1, 2x2, 3x2, 3x3, 4x3, 4x4, 5x4…
The Overview could just flatten this grid in a single array of virtual desktops, and maybe visually split the array where every row of the grid ends.

There’s another topic with the same proposal: Dynamic workspaces / virtual desktops?

1 Like

From the other topic you mentioned:

I think this is a real concern. Imagine you’ve got a 2x1 layout and you’re opening a new window on VD row 1, column 2, so a new VD is created. Now the row layout changes to 2x2.

Do we auto-create two new VDs instead of one, so you can at least navigate down in one go instead of one left, one down? Is it confusing that one time you get one new VD, another time you get two or three? Won’t it be confusing if one expansion means the next VD is on the right, but another expansion means there’s nothing new on the right (at best, you roll over to column 1?) and instead you have to navigate down to get to your new space?

I don’t know, I can’t see a way to make this happen that’s actually intuitive. Maybe someone else is more creative.

1 Like

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:

  1. Dynamic virtual desktops also means dynamic virtual desktops layout.
  2. 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:

  1. Movement in the direction of non-existent VDs is blocked.
  2. The user get redirected in the right-most VD in the row he tried to access.
  3. 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.

1 Like

Hello,
personally I very much love and use virtual desktops and I want the auto virtual desktop management. Most of the times I use 2 and rarely 3 Virtual Desktops. I do not use grid. In my opinion gird is helpful when we have a lot of virtual desktops and want to move windows comfortably.

With this perspective,

I agree with this.
Lets have a number of maximum VDs in a row “N”. When number of VDs are more than N lets create a new row to accompany the new VDs.

let N be 4 and no. of VDs are 4
VD1 VD2 VD3 VD4

let N be 4 and no. of VDs are 6
VD1 VD2 VD3 VD4
VD5 VD6

Lets call this a multi-lined VD layout instead of grid.
I prefer to show this multi-lined layout in both widget and overview.
But for grid layout we have,

  1. multi lined layout
  2. layout which tries to maximize screen utility

Maximize screen utility means that, grid view ignores multi-lined layout and tires to show X available VDs in a grid which is best suitable for the screen aspect ratio and size.

if we choose to maximize screen utility, we choose a N where people that use less to moderate number of VDs never have to enter into multi-lined layout.
else if we choose to show multi-lined layout in grid view, we have to choose a N such that the VDs in grid doesnot look too small while also keeping in mind the people who use less number of VDs.

For the navigation,
I am ok with both “2d navigation and block nvigation where there is no VD” and “1D navigation only”.

But I am leaning a little bit towards 1D navigation which is simple and encourages user not to have too many VDs.

1 Like

I propose to ditch the idea of introducing a generic mechanism to maximize screen utility, that is similar to what I initially suggested having the grid view rearranging itself so that the space was always used at its best, in favor of having a per-screen-width number of columns: if Plasma can identify what’s the best number of columns in the grid view for the current monitor, it is like maximizing screen utility without having to create another behavior.
At this point we can just have a fixed columns grid which flattens in a monodimensional array when viewed in the Overview.

What would be left to decide is the behavior of bidimensional navigation. I tried creating a mockup of the two behaviors. We could think that the Overview could try to keep the same possibility of navigating through rows, or it could lose it and just be able to move horizontally. Could this clarify things, @jpetso?

Please maximize the video frame so that you can also see the last row, as it seems that the ratio is not well fitted for screens.