Persistent workspaces

[hariseldon78]

Describe your PR, what does it fix/add?

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

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

The work was already done with the m_bIndestructible flag, I just fixed a little bug the handling in the sanity check loop.
Also I added the persistent keyword to the workspaceopt dispatcher and the output of workspace flags to the hyprctl workspaces -j command

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

It's working, i tested it on my system in a nested window, gonna test install it as system package in the next minutes.

[vaxerski]

a) why?
b) allpseudo and stuff are remnants of times long gone, I'd rather not print them. I'd prefer removing them altogether if anything...
c) you added props to json but not to non-json

[hariseldon78]

it would also be very handy to be able to specify the workspace flags at workspace creation, if any of the mantainers have a suggestion about the desired syntax I'll implement it in the workspace dispatcher.
a rough idea could be to specify the flags as a comma separated list after the workspace name, for example:

workspace name:parking,allfloat,persistent

[vaxerski]

nuh uh, allfloat is deprecated we dont do that

[hariseldon78]

a) why?
I guess you refer to why persistent workspaces?

1. the work was already initiated, just not working for a little bug, so no hurt in fixing it
2. the persistent workspaces are very helpful for some workflows.
   When requested as a feature in previous issues people have been directed to use the flag in waybar but that has some big limitations:

• the 'pseudo-persistent' workspaces can be specified at waybar start, but not created in a running session
• the Hyperland navigation commands don't consider those fake workspaces (how could it, without knowing they exists), so the only workaround i found was to open hidden windows in the workspaces to keep them from being destroyed.

3. instead of opening an issue and wasting everybody's time I thought i could give a look at the code and see if I can contribute to the project... is that bad?

Briefly my workflow that makes use of named persistent workspaces, is like this: i work on differrent projects, for different clients, so i keep a bunch of workspaces for each client named with an abbreviation of the project, for example bb1 bb2 bb3 hl1 hl2 hl3. With keybindings i can quickly navigate to a workspace and open a terminal or an editor, and a couple of scripts will open them directly in the project folder. I find it useful!
Part of the workflow is to be able to create workspaces dynamically, not only at boot.

b) allpseudo and stuff are remnants of times long gone, I'd rather not print them. I'd prefer removing them altogether if anything...

i can remove them if you say, but maybe people are using them..

c) you added props to json but not to non-json

That's true, my reasoning was that the flags were already not printed, so maybe the intention was to keep the non-json output compact, and use the json output as a programmatic interface to be queried in scripts and automation. I'll add them to the non-json part

[hariseldon78]

nuh uh, allfloat is deprecated we dont do that

ok, the point is to specify flags, not which flags... I'll make a separate PR to remove allfloat and allpseudo

[hariseldon78]

There it is, I removed the allfloat and allpseudo from output and added the persistent flag to the non-json format.

[Diaoul]

Could this solve more properly the persistent workspaces that is currently "faked" in waybar? Looks like the final step to fix #658

[Diaoul]

@hariseldon78 what is your current way of creating workspaces and setting them to persistent? Ideally I'd like to create them all on startup and then just move them around on monitors.

[hariseldon78]

@Diaoul in my hyprland.conf i bound this script:
bind = $mainMod, w, exec, ~/bin/hyprland-create-workspace.py

https://gist.github.com/hariseldon78/2fb20d04036cad8969152f379d9b70f5

The relevant part is from line 23 to 29:
hyprctl activeworkspace -j to query for workspace properties
hyprctl dispatch workspaceopt persistent to toggle the flag.

If you create them at boot then it's easier, no need to query because by default the persistent flag is off.

Feel free to use my fork to try it out, i also created an arch aur package for the time being: https://aur.archlinux.org/packages/hyprland-persistent-workspaces-git

I think the best approach, if the main dev doesn't agree to merge this, is to make it a plugin, but work is a taking more and more time and I still couldn't manage to do it. But I'll try to update my fork more frequently if i know that somebody is using it...

[Diaoul]

Thanks, I'm using the fork now ant it's working as expected. This could be a nice addition for those who wanted persistent workspaces. I tried the waybar persistent workspace feature but for some reason it creates additional ones and I end up having the same workspace number present on different monitors 😕

I see that all the review comments have been addressed. What do you think about merging this now @vaxerski? Even if it's not the best way to implement this, it works for a minimal footprint in the code, that's something.

[vaxerski]

workspaceopt is horrible, and on track to be deleted. I'd rather this was a workspace rule.

See CConfigManager::handleWorkspaceRules for handling

[hariseldon78]

That could work only if we are able to add/remove those rules at runtime, not only at config time.
I can try and code a couple of dispatchers, something like "addworkspacerule" and "removeworkspacerule".
Would that be ok?

[Diaoul]

@hariseldon78 can't you do it at runtime already with hyprctl keyword workspace?

e.g.

hyprctl keyword workspace "1, monitor:eDP-1"

[vaxerski]

exactly as above.

[hariseldon78]

ah that's perfect then, I'll do it

[hariseldon78]

@vaxerski @Diaoul here it is, I've sent this other pr: #3530. I'll close this one then