Feat: Add new optional "default command" for auto-launching apps on new workspaces

[Syndelis]

Describe your PR, what does it fix/add?

Update 13/10/2023

The PR has been updated to introduce a workspace rule as suggested below, rather than an additional parameter to the workspace and togglespecialworkspace dispatchers.

About this PR

This PR introduces a new workspace rule that allows the user to define a command to be run when switching to a new workspace.

The command gets passed to spawn(), which is virtually equivalent to calling hyprctl dispatch exec "<your_command>". This means that you can also use the same execution rules that exec supports. It's worth noting that the execution rule workspace <workspacename> is explicitly overwritten to the workspace the rule has been attributed to. Even if you didn't set it, it will be set automatically.

This required two new methods to be added to VarList: append and map.

The Motivation

My biggest use case for special workspaces is to quickly use and hide a terminal, and I absolutely adore Hyprland for having those. However, the setup requires me to 1) launch a terminal and 2) move it to the special workspace. With this feature, I can always press the special workspace shortcut and launch a terminal if there wasn't one already.

I can also see more organized other people use this to auto-launch their favorite browser when switching to their designated "Browser" workspace.

"But you can achieve the same with a script/other shortcut"

Indeed, but the beauty of Hyprland (to me, at least) is how much convenience it brings out-of-the-box, with key manager, device settings and (of course) animations. I believe this is one more convenience most would find useful.

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

Nothing that comes to mind.

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

Ready for merging.

Demo Video

hyprland_workspace_rule_cmd_h264.mp4

Configuration used in the video

# Opens 'foot' if workspace doesn't already exist
workspace = special:scratchpad, on-created-empty:foot

# Opens *floating* foot if workspace doesn't already exist
workspace = 5, on-created-empty:[float] foot

[MightyPlaza]

you can already open programs on a workspace at start with exec = [workspace special silent] foot and simply not close them

that being said, the option of doing this as a workspace rule, despite giving less freedom, might be worth considering

[Syndelis]

you can already open programs on a workspace at start with exec = [workspace special silent] foot and simply not close them

I don't think that's a realitic comparison to this feature. I personally work with low-memory devices and can't afford to keep apps open just for the convenience of access. Not to mention even idle apps can be hogs to a laptop's battery.

that being said, the option of doing this as a workspace rule, despite giving less freedom, might be worth considering

I'm curious about what you mean by "giving less freedom". The implementation specifically levarages from the same function that handles the exec dispatcher, so you can launch windows with all the same rules supported. Of course, being implemented in both dispatchers that "move" you to another workspace does means that the "silent" rule doesn't appear to make a difference.

[MightyPlaza]

I'm curious about what you mean by "giving less freedom"

With current implementation you can chose to open the workspace with, without or even with different commands
Doing it as a workspace rule would remove this possibility, but would make it more uniform (ex: workspace +1) and script friendly
the question is which behavior is better

[Syndelis]

With current implementation you can chose to open the workspace with, without or even with different commands Doing it as a workspace rule would remove this possibility

I'm sorry, I still didn't get it 😅 ! I'm not sure if this is the adequate answer to your point, but if it helps: the new parameter is optional, so you can still move to workspaces without triggering a command, like the following:

# Moves to workspace 1, nothing much
bind = SUPER, 1, workspace, 1

# Moves to workspace 2 and, if it didn't exist, launches firefox on it
bind = SUPER, 1, workspace, 2, firefox

[FakeMichau]

To me it sounds like something niche enough that it would be better off as a plugin or a script, not part of the main project.

[MightyPlaza]

i mean something like

workspace=2, on_create: [float] firefox

instead of

# Moves to workspace 1, nothing much
bind = SUPER, 1, workspace, 1

# Moves to workspace 2 and, if it didn't exist, launches firefox on it
bind = SUPER, 1, workspace, 2, firefox

the workspace rule implementation would not allow for this separate behavior

[Syndelis]

To me it sounds like something niche enough that it would be better off as a plugin or a script, not part of the main project.

I hope it doesn't come off as me being rude or overprotective of this PR, but I do think this could be said about a lot of features Hyprland offers when compared to other compositors such as Sway. However, I believe that it's exactly because Hyprland does a lot that it's such a blast to use; it magically seems to fit to everyone's needs.

With that being said, while you believe this is niche enough to be a plugin, I think it would be quite the overkill to make a plugin specifically for this functionality. After all, the changes only add a couple extra operations to the process of moving to a new workspace, which can pretty much be considered negligible both in performance and maintenance costs. Would love to hear your opinion on this, though.

[Syndelis]

i mean something like

workspace=2, on_create: [float] firefox

instead of

# Moves to workspace 1, nothing much
bind = SUPER, 1, workspace, 1

# Moves to workspace 2 and, if it didn't exist, launches firefox on it
bind = SUPER, 1, workspace, 2, firefox

the workspace rule implementation would not allow for this separate behavior

Oh, gotcha! I initially misunderstood it when you said "workspace rule"; I had completely forgotten about these. That said, I'm also unsure of where this feature would be better implemented at. I'm still leaning towards the behavior implemented in this PR because the syntax the new parameter follows is the same as exec, which is more likely to be used by key bindings. Nothing against moving it though!

[GabrielFoxDev]

I'd just like to point out that it is pretty common to see in r/unixporn, for instance, setups in which each workspace is represented as an icon to a specific purpose, such as web browsing, as suggested by @Syndelis, or coding/programming, instant messaging, reading, content creation, so forth and so on.

This feature would allow for a more out-of-the-box configuration experience, in which one could lean on a highly efficient implementation (as opposed to the vast majority of alternative solutions) and not have to write their own scripts for quality of life functionality.

I agree with @MightyPlaza on whether it is worth considering to implement this feature as a workspace rule, as it does make sense to couple this kind of behavior to the workspace itself. On the other hand, I'd also take into consideration that by coupling it to a workspace switch bind instead, one could use different binds to open different applications with the same overall purpose in the same specific workspace, if so desired.

One use case I have in mind is having mutiple browsers to open on a workspace specific for web app testing purposes.
Another one is for Krita, Gimp and Kdenlive.

[vaxerski]

I am in favor of this being in a workspace rule.

Also I was thinking, on a tangent, maybe we should allow mixing workspace rules? 🤔

[Syndelis]

Based on the feedback initially given by @MightyPlaza and supported by @GabrielFoxDev and @vaxerski, commit 0bbad21 removes the optional parameters from the dispatchers and introduces a new workspace rule that serves the same purpose.

The PR's description has been slightly altered to match the new implementation, and a new demo video reflecting the change has been linked.

As a sidenote, a cool side effect this change introduced is that switching to a workspace using relative IDs (r+1, e+1, etc) also trigger the effect, which would previously not be possible. Thanks again for the feedback, @MightyPlaza!

[yavko]

Wouldn't it be better to take a dispatcher, so you could do other things separate from starting a new program?
ex:

workspace = special:scratchpad, on-created-empty:exec,foot

[vaxerski]

hyprctl dispatch ...?

[vaxerski]

rest is lgtm, except it needs a clang-format

[Syndelis]

rest is lgtm, except it needs a clang-format

I'd hesitated to use it at first because it touched a few lines that I hadn't changed myself. Eitherway, I've ran it and committed the changes in 1c3746f

[vaxerski]

I know, for some reason clang-format on my desktop behaves a bit weirdly.

[vaxerski]

lgtm, thanks!

soulja.boy.mp4

[vaxerski]

we just need a wiki mr

[Syndelis]

we just need a wiki mr

Sure thing, will open it and link it here! Thanks

Edit: I've opened the PR in hyprwm/hyprland-wiki#375