Improving virtual desktops in KDE

Brainstorm
1

Hello,

(I wrote what i wanted first than used AI to correctly explain my ideas i could give the original version but this is more understandable)

I moved from GNOME to KDE and the only thing I miss is dynamic virtual desktops. But KDE has the grid view and nameable desktops, so it isn’t as straightforward to implement as in GNOME.

1. Describing the grid layout

To have a dynamic number of VDs that grow and shrink while staying compatible with a 2D grid, we first need a way to describe how the layout is arranged when a VD is added or deleted.

I think we should drop the current “rows” setting, which is too restrictive. It would be better to have:

  • max_columns: how many desktops fit in one row (1 to N, or unlimited)
  • max_rows: how many rows the grid can have (1 to N, or unlimited)
  • horizontal direction: left-to-right or right-to-left
  • vertical direction: top-to-bottom or bottom-to-top
  • fill order: row-first (fill the current row, start a new row when it’s full) or column-first (fill the current column, start a new column when it’s full)

The underlying model stays simple: desktops remain an ordered list, and the grid is just that list wrapped according to these settings. That means no holes are possible, and adding or deleting a desktop simply re-wraps the grid.

2. Static desktops still work

Even without enabling dynamic VDs, people can keep their static layout: they choose the grid settings and fill the layout with desktops. Ctrl + and Ctrl - would follow those settings.

A fully horizontal workspace is possible (max_columns = unlimited, max_rows = 1, L→R, row-first). A single vertical column is possible (max_columns = 1, max_rows = unlimited, T→B, column-first). A 3×2 grid is possible (max_columns = 3, max_rows = 2, L→R + T→B, row-first, giving 1 2 3 / 4 5 6). RTL users can flip the horizontal direction to get 4 3 2 1 on a single row.

3. Dynamic naming

I’d like a setting for the default workspace name, with a variable inside representing the desktop position:

  • I could set "Desktop {position}", or rename the template to "Workspace {position}", and it would always reflect the desktop’s position in the grid.
  • Other useful variables: {row}, {col}.
  • Names using the template recalculate automatically when the grid reorganises.

4. Behaviour of dynamic VDs

When enabled:

  • A VD with no windows is automatically deleted.
  • If the last VD has a window, a new one is added, following the grid layout settings.

So with max_columns = unlimited, max_rows = 1, direction L→R and row-first fill, we get a GNOME-like layout: desktops keep appearing to the right and empty ones disappear. If I want a new row every 3 workspaces, I set max_columns = 3, max_rows = unlimited, L→R + T→B and row-first: desktops 1 to 3 sit on the first row and a new row starts at 4. And max_columns = 1, max_rows = unlimited, T→B with column-first gives a vertical GNOME.

5. Minimum number of dynamic workspaces

It would be nice to have a “minimum dynamic workspaces” setting, for people who always want at least 3 workspaces around before the system starts adding more.

Important: those 3 are still dynamic, and the setting is a count floor, not a position floor. With min = 3 and 4 workspaces open, emptying the second one still deletes it, since 3 remain and that’s fine. Emptying another one after that would leave only 2, so that one stays.

Ctrl + would still work in the overview to add VDs manually. If such a VD is never populated with at least one window, it gets cleaned up by the normal auto-delete rule when the overview is closed.

6. Pinned desktops (optional)

This one I’d like, but I’m not sure it should be included since it adds some complexity: when dynamic VDs are enabled, it could be possible to mark VDs as ignored by auto-deletion, at the start or at the end of the layout. So I could have two fixed desktops at the beginning that never move and keep their names, followed by dynamic ones that grow and shrink.

For example, with max_columns = 4, max_rows = unlimited, L→R + T→B and row-first, desktops 1 and 2 could be pinned as “Mail” and “Music”. They never move or get deleted, and everything after them grows and shrinks and fills the rest of the grid.

Here is a demo i vibe coded : Claude Artifact

2

random thoughts, in no particular order

seems to me for dynamic to work you must prohibit limiting either rows or columns because if both are limited, then dynamic has no where to add the next VD.

never used gnome but it seems to me that it is much easier to add a VD in plasma (there are mutiple ways) so that having it be automated is not that much of an advantage.

naming could get weird if one of your named VD were to get pruned by dynamic and then when one is added back it is given a new name but still in the same place as where your named one was…

just seems fraught with additional cognitive load for the user when naming and placing VC that STAY PUT is much less of a burden.

3

For the first issue in the demo you can select unlimited for max rows or col to add VD’s infinitly, also it is cool if someone wants their grid to have a max size, also another way of fixing this would be to choose only one value that follows the grow vertically or horizontaly

for naming i think it is ok, in the demo they are dynamic too, if we consider dynamic VD’s as ephemeral i find it ok to rename one temporarly you know it will be deleted anyway, that is why you can keep them as static and that why i though about the « ignored VD’s » at start and end of layout so you keep some that will never be deleted and renamed (in the demo too)

For if it is an advantage a lot of people like me want ephemeral VD’s and don’t to use them as a rigid anchor, maybe adding them are easy (crtl +), deleting one specially in the middle is a hassle, you need to move your mouse, and even than the naming becomes broken, and like i said it is a feature, i think it makes sense, it could enabled or disabled by default, people could keep their static VD’s that don’t move (it is KDE it is about choice)

4

This feature merge request may be of interest to you:

It uses square root of the maximum count to set dynamic row/column counts for the Overview’s Grid effect. Sounds like what you’re describing!

5

If i understood correctly this turns the grid from displaying the real layout of your VD’s to how to fit most VD’s on screen, but the grid don’t represent the real layout. My idea adds a way to control how the layout behaves with adding or removing VD’s, so the grid view will always display the real layout. I mean this could still live with my idea, and toggle this for people that want the grid view to be a way to see all your workspaces in the most efficient way

6

What I do is I run a 3×3 grid that I map to the NumPad: