Persistent workspace rule

[hariseldon78]

Describe your PR, what does it fix/add?

It allows to mark a workspace as persistent, inhibiting removal during the sanity check. Usage:

hyprctl keyword workspace name:wspers,persistent:true
hyprctl dispatch workspace name:wspers

Is there anything you want to mention? (unchecked code, possible bugs, found problems, breaking compatibility, etc.)

It's been decided to implement this feature as a workspace rule, after the conversation at #3346

Is it ready for merging, or does it need work?

Tested and ready for merging.
If it's welcome i could follow up with another PR for querying the workspace rules, I didn't find a command for that but I may be wrong.

[vaxerski]

all good, thanks!

[niksingh710]

This works great but now e+1 and r+1 behave in same manner is it an expected behavior?

[hariseldon78]

This works great but now e+1 and r+1 behave in same manner is it an expected behavior?

Not sure, i only use r+-1. Maybe I'll test it this weekend.

[githubber6800]

Not sure if this is intentional, but e+-1 and m+-1 wont navigate to a persistent workspace if its empty. It would be cool if it did, or if you could make it so.

If the workspace aren't empty e+-1 and m+-1 would loop around from the last workspace to the first. r+-1 makes a new workspace, then a new one and so on instead of looping, which is fine but a different workspace experience.

[hariseldon78]

I'm sorry for not having enough time to address this quickly, i'll try to use e+-1 and m+-1 which I'm not using right now, and then I'll take a look at the code. I already started, but it's complex and I don't want to risk breaking anything.
The navigation commands at the moment know nothing about the persistent nature of a workspace, because they were implemented before. Maybe the best approach could be to add yet another navigation indicator that fit better the use case of having many empty workspaces.

[johnr14]

I am using multiple monitors and keybinds for m+1 e+1.
This PR is has quite a good prospect.

@hariseldon78 for navigation of workspaces on a monitor, would a method to reorder them in a stack be of use ? (it can be named something else if there is a more appropriate name)

Something like :
workspacestack
workspacestack, moveactive, (s+1|s-1)|top|bottom
workspacestack, autoreorder, (monitor_x|current), opt_method an|na
workspacestack, move, wsname|wsnumber, (s+1|s-1) | pos#|top|bottom
workspacestack, workspace, (s:pos|top|bottom) # go to X on stack

config :
workspacestacksort : alphanum|numalpha # default shorting an|na

Workspace stack should be relative to a monitor.
s:pos# would always start at 0 and second workspace on monitor would be 1 (no matter it's name or id).
We could have s+1, s-1 and s:X for stack operation.

Personnaly I think stack should be a submember of workspace instead of having an other dispatcher action.
It would be best to have it's dispatch method as :
workspace, stack, action, args, & optargs

I can see many use for a stack implemented like this.

• move current active workspace to monitor_2 and set it's position at 0.
• move active window to monitor_2 at workspace stack position 4.
• useful if you name your workspace and want to move to 3rd workspace.

Thanks for your work !

[hariseldon78]

@johnr14 hey, glad that you like the feature. I already solved the problem of sorting the workspaces with a script, try and see if it does at least part of what you envision: https://gist.github.com/hariseldon78/d0b91e584fa97e3efcbd280cf1703f5f

That said I'm not sure how much the main developer would agree to add too much complexity on the workspaces management, and if it's something that would fit better on a plugin we can use that tool.

[johnr14]

Wow, @hariseldon78 it's cleaver how you did it.

I can't check it for the moment.

I do hope workspace would get a stack like how the window does.

As it would be easier to bind MOD+1 to be always be the first workspace on current monitor, no matter it's name or id. And it would be nice to move workspaces around on a monitor with something like MOD+CTRL+left|right.

Scripting is great, but having a good dispatcher interface is mandatory to bring hyperwm to a general public. I am of those that doesn't have a lot time to spend on tuning my system, I need it to just work, but I want a good tiling manager and not a KDE|Gnome with a bunch of plugins.

Thinking about how to go with your problem, I wrote #3805 as I found it hard to lookup information on the wiki.

Thanks and I'll wait for the PR to be merged to upgrade to git with yay on arch.