When named workspaces are defined, don't dynamically create an un-named workspace automatically after the named workspaces

[mexisme]

When named workspaces are defined, it would be nice to not have a un-named workspace automatically/dynamically created after the named workspaces.

However, if I move past the last named workspace (e.g. focus-workspace-down or focus window <index>) it would be nice for an un-named workspace to be created at the end.

The context is that when I'm using named workspaces, I usually don't need additional un-named workspaces.

[YaLTeR]

Hey,

The way dynamic workspaces work in niri is that there's always an empty workspace in the end. So it is created as soon as some window appears on the last workspace, rather than completely on-demand. This is better functionally, because you can always interact with that workspace (i.e. spawn a window on it), rather than being limited to spawning on an existing workspace and "moving down" or something. It also always lets you use your mouse to navigate to the last empty workspace, since it is always displayed.

I think instead of changing this behavior in niri (would be very annoying and prone to regressions), it should be an option in the bar application to hide the last workspace if it is empty.

[Ornanovitch]

That's exactly what I was looking for yesterday: a way to hide the automatic workspace in waybar :)

[mexisme]

Hey,

The way dynamic workspaces work in niri is that there's always an empty workspace in the end. So it is created as soon as some window appears on the last workspace, rather than completely on-demand. This is better functionally, because you can always interact with that workspace (i.e. spawn a window on it), rather than being limited to spawning on an existing workspace and "moving down" or something. It also always lets you use your mouse to navigate to the last empty workspace, since it is always displayed.

I think instead of changing this behavior in niri (would be very annoying and prone to regressions), it should be an option in the bar application to hide the last workspace if it is empty.

While that does make sense from a user-interaction, and (perhaps) internal optimisation point-of-view, it seems a bit unnatural for interacting with workspace API from a task-bar.

Would it be possible to instead (somehow) mark a workspace as "hidden" and therefore for it to not show in the workspace list while it is hidden?
If it were possible to configure Niri to mark the empty workspace as hidden until it was used, that would seem an elegant solution.
Which also seems somewhat related to how other compositors support scratch workspaces?

As a background explanation: I've created a named workspace called "scratch" in the absence of having one in Niri.
This request was because I was hoping to make it the last one in the list and not have an empty one created after it.

It would also be a nice touch to be able to hide it when it's not in-view.

[mexisme]

Hey,

The way dynamic workspaces work in niri is that there's always an empty workspace in the end. So it is created as soon as some window appears on the last workspace, rather than completely on-demand. This is better functionally, because you can always interact with that workspace (i.e. spawn a window on it), rather than being limited to spawning on an existing workspace and "moving down" or something. It also always lets you use your mouse to navigate to the last empty workspace, since it is always displayed.

I think instead of changing this behavior in niri (would be very annoying and prone to regressions), it should be an option in the bar application to hide the last workspace if it is empty.

(Thanks for the detailed reply, btw)

[YaLTeR]

While that does make sense from a user-interaction, and (perhaps) internal optimisation point-of-view, it seems a bit unnatural for interacting with workspace API from a task-bar.

But... it is natural? The workspace is there, you can click to switch to it. Then click on, I don't know, an icon in an app dock to open a new window on the workspace.

Which also seems somewhat related to how other compositors support scratch workspaces?

It is not a scratch workspace though. People are requesting scratch workspaces separately, it's a completely different feature.