[BUG] Empty workspace not found

[GuzioMG]

yes, the title is a pun based on how this is issue #404

When switch_workspaces: true is set in switch-config and you attempt to switch while having an empty workspace opened - some weird behaviour happens. I will update this issue with screenshot of said weird behaviour (there is really no good way to describe it without a visual aid), but (as I said in #403) I currently don't have a usable screenshot tool in my Hyprland, so I need to move this issue to my phone (from where I'll post photos of my screen). Please consider this a issue stub that I totally didn't open early, just to claim that pun-like ID.

[GuzioMG]

The problem:

When switch_workspaces: true is set in switch-config and you attempt to switch while having an empty workspace opened - the following happens:

It starts as-expected:

...With the 2nd (most recent) choice selected, and the GUI looking like normal:

Then, you press TAB...

...and (again, as expected) it moves forward by a single field. And again, and again, until you reach the end of the GUI:

Then, it enters the imaginary numbers plane:

Just kidding. It stays in the naturals (workspace nr 1). Although it definitely feels like it because appears as of your selection completely ceased to exist (just like a point on a number line, when you're only looking at reals):

However, it is still there - you just cannot see it (just like a point, when- okay, enough overusing the same math joke). It's currently selecting the empty workspace 1 (as I said earlier). I know that because if I were to release my modifier key now, my mouse would move to the other screen (which only has workspace 1). This - by the way - shouldn't be possible. If you read #403, you'll see that I filter my workspace switcher by current_monitor. So why the hell did it switch monitors? I have no idea!

You Tab again...

Still, you see the same:

This time, I believe it's highlighting workspace 5 (because it doesn't move your mouse across screens). This, too, seems like some fundamental violation, however - because alt-tab menus generally sort by recency, and WS5 was the more recent one for me. So while I understand why empty workspaces would be at the end, as a group (there's usually no reason to open an empty workspace) - I don't see why the items inside that group wouldn't be sorted by recency.

The final Tab - in shock, fear and confusion:

Finally, it wraps back to the 1st entry!

Expected behavior:

Just like in #403, I can see two ways out:

Treat empty workspaces with proper care and love

The 1st option is to embrace this bug(???) of being able to switch into empty workspaces, and use it to your advantage. To that extent, the following changes should be made:

• Make empty workspaces properly show up in the Switcher GUI, just like all other workspaces, instead of eating your selection.
• Let special workspaces use Hyprshell's recency-based sorting, instead of getting awkwardly squished into the end of the list and sorted by number. I can understand the first one (it's not often that you need to switch to a particular instance of an empty workspace, so it may be more convenient to have them at the end), although it should perhaps be configurable for anyone who needs it - but the 2nd one seems incomprehensible to me (unless it wasn't an intentional choice but a bug - which it probably was).
• Make empty workspaces properly follow the current_monitor filter. Speaking of filters: It's worth pointing out that some users might not want to see those empty workspaces at all (me included), so in a recent comment to [FEATURE REQUEST] Add a filter to hide special workspaces and/or particular classes #403 I described what could be done to let users filter out all unwanted empty workspaces (boils down to 2 solutions: a multi-criteria filter, or adding some text for regex to detect).

Properly remove empty workspaces from the list

When tab-ing on the last entry (or grave-ing on the 1st one), properly wrap your selection around the list, instead of sending it to the Shadow Realm.

[H3rmt]

Finaly managed to reproduce this

[H3rmt]

I think v4.10.4 should have fixed this, can you still reproduce it?