Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Merged

Conversation

Syndelis
Copy link
Contributor

@Syndelis Syndelis commented Oct 12, 2023

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor Author

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor Author

Syndelis commented Oct 12, 2023

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
Copy link
Contributor Author

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
Copy link

GabrielFoxDev commented Oct 13, 2023

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
Copy link
Member

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
Copy link
Contributor Author

Syndelis commented Oct 14, 2023

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!

src/Compositor.cpp Outdated Show resolved Hide resolved
src/config/ConfigManager.cpp Outdated Show resolved Hide resolved
src/helpers/MiscFunctions.cpp Outdated Show resolved Hide resolved
src/helpers/MiscFunctions.cpp Outdated Show resolved Hide resolved
src/managers/KeybindManager.cpp Outdated Show resolved Hide resolved
src/managers/KeybindManager.cpp Outdated Show resolved Hide resolved
src/managers/KeybindManager.cpp Outdated Show resolved Hide resolved
@yavko
Copy link
Member

yavko commented Oct 21, 2023

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
Copy link
Member

hyprctl dispatch ...?

Copy link
Member

@vaxerski vaxerski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

rest is lgtm, except it needs a clang-format

src/Compositor.cpp Outdated Show resolved Hide resolved
src/config/ConfigManager.hpp Outdated Show resolved Hide resolved
src/helpers/MiscFunctions.cpp Outdated Show resolved Hide resolved
@Syndelis
Copy link
Contributor Author

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
Copy link
Member

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

Copy link
Member

@vaxerski vaxerski left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

lgtm, thanks!

soulja.boy.mp4

@vaxerski
Copy link
Member

we just need a wiki mr

@Syndelis
Copy link
Contributor Author

Syndelis commented Oct 22, 2023

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

Syndelis added a commit to Syndelis/hyprland-wiki that referenced this pull request Oct 22, 2023
the new workspace rule is being introduced in hyprwm/Hyprland#3559
vaxerski pushed a commit to hyprwm/hyprland-wiki that referenced this pull request Oct 22, 2023
@vaxerski vaxerski merged commit b135bd6 into hyprwm:main Oct 22, 2023
11 checks passed
@Syndelis Syndelis deleted the feat/default-cmd-for-empty-workspace-switching branch October 22, 2023 22:29
fufexan pushed a commit to hyprwm/hyprland-wiki that referenced this pull request Dec 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

7 participants