config: workspace empty behavior

[kotarac]

Implementation according to our discussion here #541.
Closes #519.

[mahkoh]

In case you wrote the book changes by hand: You don't have to do that. There is already enough busy work when adding new features.

[kotarac]

In case you wrote the book changes by hand: You don't have to do that. There are already enough busy work when adding new features.

I did not actually. I've had gpt-5.2 write the book content and before that help me better clarify the behavior of each value in spec.yaml and review the changes. Or to be precise, review the changes and then do all that.

Btw, possibly interesting piece of info: I've tried letting it help write a testcase in the integration test and I ended up with a couple GiB worth of logs in testruns/ dir because it destroyed a wl_surface before destroying a wl_viewport, resulting in leak tracking going crazy with logging.

Still need to get around to testing this on multiple outputs. I only have such setup at the office and unfortunately I haven't had any time lately to sit down and go through it.

[kotarac]

In case you wrote the book changes by hand: You don't have to do that. There is already enough busy work when adding new features.

Also, fwiw, while this is true and the book and control center added more, I don't really mind this at all.

In my 1st Jay contribution on the touchpad stuff, it took quite some time to go through everything, but the 1st moment I've had it compile it actually worked correctly (despite having multiple style/consistency issues) which is at least partly because of the way it's set up right now.

I suppose some of it could be distilled now to somehow have 1 central place which dictates how all "touchpoints" work, but it's not exactly a big deal once you know where everything is.

[mahkoh]

If you only have one display you can manually test this using virtual outputs and wl-mirror or obs.

[kotarac]

If you only have one display you can manually test this using virtual outputs and wl-mirror or obs.

Got one now actually, just need to get around to it. Rebasing it to stay up to date as I'm dogfooding this. 🙂

[kotarac]

Needs a bit more work, couple of edge cases to go through and some more ext_workspace_manager_v1 work which has 0 test coverage and I don't usually use it.

[kotarac]

-.-

[mahkoh]

I feel like hidden workspaces should stay attached to their output. That would also remove the need to find the correct output when unhiding the workspace and would keep the workspace in the same position as before.

Sometimes it might be useful to have a linked list containing only the visible workspaces. For such cases it might be useful to maintain two linked lists per output. One containing all workspaces and one containing only the visible workspaces.

[kotarac]

I feel like hidden workspaces should stay attached to their output. That would also remove the need to find the correct output when unhiding the workspace and would keep the workspace in the same position as before.

Hmm, that would help. And yes, the current approach didn't place it back where it was in case the display order was manual.

Sometimes it might be useful to have a linked list containing only the visible workspaces. For such cases it might be useful to maintain two linked lists per output. One containing all workspaces and one containing only the visible workspaces.

👍

[kotarac]

Think the separate linked list only for visible workspaces is needed? Seems cheap to just filter out hidden ones where needed, but it is inconvenient that it's done in multiple places though...

[kotarac]

FTR since the last review, I discovered a small issue when destroy is set with floating windows, that's another extra change since.

[kotarac]

Moved it to draft. It's been a while, a lot has changed, and I haven't had time/willpower to move it. Will see if I can find some time to test it properly again.

[mahkoh]

Don't worry about it.