Implement hooks (running commands) #174

Hanker commented 2025年07月04日 05:25:08 +02:00

Matugen has a post hook that is usually used to reload applications after their configuration file has changed, which is just a shell command.

It also has a wallpaper section in its configuration where you can specify the command to run to set the wallpaper if required.

I think both of these would be great additions to wallust!

[Matugen](https://github.com/InioX/matugen) has a post hook that is usually used to reload applications after their configuration file has changed, which is just a shell command. It also has a wallpaper section in its configuration where you can specify the command to run to set the wallpaper if required. I think both of these would be great additions to wallust!

explosion-mental commented 2025年07月05日 02:25:59 +02:00

Sounds interesting and totally useful. But why should this app invoke a "post hook", when you can simply wrap it up in a script?

This is a design choice I've left because these programs are usually called in pair with other programs that also "rice" stuff, and it usually gets it's way into a script of some sort, just like pywal. I think using that adds complexity that isn't required, when you can simply call whatever you like in your scripts.

tldr; using a script solves both problems

pd: However, I'm still considering the wallpaper bit since on windows and macos you can change the wallapaper in one way, but for linux there is multiple programs for it so it would require special handling, detection or the like for those programs.

Sounds interesting and totally useful. But why should this app invoke a "post hook", when you can simply wrap it up in a script? This is a design choice I've left because these programs are usually called in pair with other programs that also "rice" stuff, and it usually gets it's way into a script of some sort, just like pywal. I think using that adds complexity that isn't required, when you can simply call whatever you like in your scripts. tldr; using a script solves both problems pd: **However**, I'm still considering the wallpaper bit since on windows and macos you can change the wallapaper in one way, but for linux there is multiple programs for it so it would require special handling, detection or the like for those programs.

Hanker commented 2025年07月05日 07:42:16 +02:00

It is mainly to reduce the reliance on scripts and also to make things easier to iterate and test for the user. A lot of times, the script that "rice" stuff is a whole pipeline that includes a lot of different parts and applications, which makes it difficult to break down and test. You could definitely write the script to take arguments to invoke only certain parts of the pipeline, but that makes the script far more complicated for little gain, as once you are done iterating, you have no need for that complexity in the script.

I find that being able to use wallust run /path/to/image and have all my applications reload would be easier for iterating and testing, since that is what I always want to do, and would simplify the script quite a lot. I also think that the complexity gain in wallust might not be that much if following Matugen, as the post command hook is just a string.

But yes, I agree that scripts solve the issue, as that is what I am currently using.

I think the wallpaper bit could be handled in a similar way to how Matugen handles the wallpaper command, which is a command field and an array of arguments to pass to the command with sensible defaults for Windows and macOS.

It is mainly to reduce the reliance on scripts and also to make things easier to iterate and test for the user. A lot of times, the script that "rice" stuff is a whole pipeline that includes a lot of different parts and applications, which makes it difficult to break down and test. You could definitely write the script to take arguments to invoke only certain parts of the pipeline, but that makes the script far more complicated for little gain, as once you are done iterating, you have no need for that complexity in the script. I find that being able to use `wallust run /path/to/image` and have all my applications reload would be easier for iterating and testing, since that is what I always want to do, and would simplify the script quite a lot. I also think that the complexity gain in wallust might not be that much if following Matugen, as the post command hook is just a string. But yes, I agree that scripts solve the issue, as that is what I am currently using. I think the wallpaper bit could be handled in a similar way to how Matugen handles the wallpaper command, which is a command field and an array of arguments to pass to the command with sensible defaults for Windows and macOS.

explosion-mental commented 2025年10月13日 22:42:37 +02:00

Well, since this is asked twice, I decided to think about adding this. would running a script be enough? Similar to sxiv/nsxiv, that reads a script with a hardcoded path, given that post hooks don't really use anything from the program itself. Another option would be the classic way that you ask, I imagine it designing it as something:

[hooks]
fox = 'pywalfox run $WALLPAPER'
gtk = 'gtkupdater run ..'

And the like, it seems to me it just feels like a script at this point, but gets to the needs of the users, and in that thought, What is your usecase?

Well, since this is asked twice, I decided to think about adding this. would running a script be enough? Similar to sxiv/nsxiv, that reads a script with a hardcoded path, given that post hooks don't really use anything from the program itself. Another option would be the classic way that you ask, I imagine it designing it as something: ```toml [hooks] fox = 'pywalfox run $WALLPAPER' gtk = 'gtkupdater run ..' ``` And the like, it seems to me it just feels like a script at this point, but gets to the needs of the users, and in that thought, What is your usecase?

Hanker commented 2025年10月14日 03:13:11 +02:00

For me, I prefer the post hook approach as it is more granular, and keeps everything related to changing themes in Wallust’s configuration file, which makes it easier to iterate on and maintain. I prefer to write less scripts, but that’s my preference.

For post hooks/script in general, the main draw is to not need a wrapper script to call wallust to change the theme of all applications, as reloading applications is usually necessary for theme changes.

For me, I prefer the post hook approach as it is more granular, and keeps everything related to changing themes in Wallust’s configuration file, which makes it easier to iterate on and maintain. I prefer to write less scripts, but that’s my preference. For post hooks/script in general, the main draw is to not need a wrapper script to call wallust to change the theme of all applications, as reloading applications is usually necessary for theme changes.

explosion-mental commented 2025年10月15日 18:36:21 +02:00

I'm taking a look at matugen configs and made me think. Should the implementation contemplate pre/post hooks? If you use that feature, may you elaborate a bit on your workflow? Think it should be simple enough to add different pre and post hooks, but is it really useful (as in, being used)?

I'm taking a look at [matugen configs](https://github.com/InioX/matugen/wiki/Configuration) and made me think. Should the implementation contemplate pre/post hooks? If you use that feature, may you elaborate a bit on your workflow? Think it should be simple enough to add different pre and post hooks, but is it really useful (as in, being used)?

Hanker commented 2025年10月16日 05:17:43 +02:00

Personally, I don’t use pre-hooks and I don’t really know of anyone using it. All of the Matugen configurations I have seen only make use of the post hook.

In Matugen’s case, the pre-hook on the wallpaper makes sense to reload to wallpaper daemon, but I don’t think it’s useful for templating.

The pre-hook means the hook is executed before templating is done, but after wallust has generated the theme, which doesn’t seem very useful other than for modifying template files. In such cases it would make more sense to just modify the template file directly or manually, especially since the templating language is powerful enough for dynamic configurations in my opinion.

Maybe someone who uses a template that depends on the output of a shell script or command can chime in, but I think it is a very rare use case.

Personally, I don’t use pre-hooks and I don’t really know of anyone using it. All of the Matugen configurations I have seen only make use of the post hook. In Matugen’s case, the pre-hook on the wallpaper makes sense to reload to wallpaper daemon, but I don’t think it’s useful for templating. The pre-hook means the hook is executed before templating is done, but after wallust has generated the theme, which doesn’t seem very useful other than for modifying template files. In such cases it would make more sense to just modify the template file directly or manually, especially since the templating language is powerful enough for dynamic configurations in my opinion. Maybe someone who uses a template that depends on the output of a shell script or command can chime in, but I think it is a very rare use case.

explosion-mental commented 2025年11月30日 04:20:07 +01:00

@Hanker mind testing it out, I think it follows your needs, feedback is appreciated :)

example confg:

[hooks]
xorg = "notify-send 'hi'"
sleep = "sleep 10"

@Hanker mind testing it out, I think it follows your needs, feedback is appreciated :) example confg: ```toml [hooks] xorg = "notify-send 'hi'" sleep = "sleep 10" ```

explosion-mental commented 2025年11月30日 04:26:05 +01:00

It also has a wallpaper section in its configuration where you can specify the command to run to set the wallpaper if required.

Btw, lets leave the wallpaper setting for now, since its only foward with Windows.

In unix, you can simply add it to the hooks.

[hooks]
wallpaper = """swww img "$(find ~/Media/Pictures/Wallpapers -iregex '.*.\\(jpg\\|jpeg\\|png\\|gif\\)' -type f | shuf -n 1)" """

Since this spawns a shell, you can do that kind of stuff. From the start, I dislike the idea of spawning programs from within another, unless it has such an importance like window managers. However I don't think it's that bad since this program doesn't require additional privileges.

> It also has a wallpaper section in its configuration where you can specify the command to run to set the wallpaper if required. Btw, lets leave the wallpaper setting for now, since its only foward with Windows. In unix, you can simply add it to the hooks. ```toml [hooks] wallpaper = """swww img "$(find ~/Media/Pictures/Wallpapers -iregex '.*.\\(jpg\\|jpeg\\|png\\|gif\\)' -type f | shuf -n 1)" """ ``` Since this spawns a shell, you can do that kind of stuff. From the start, I dislike the idea of spawning programs from within another, unless it has such an importance like window managers. However I don't think it's that bad since this program doesn't require additional privileges.

Hanker commented 2025年11月30日 09:01:42 +01:00

@explosion-mental wrote in #174 (comment):

@Hanker mind testing it out, I think it follows your needs, feedback is appreciated :)

example confg:

[hooks]
xorg = "notify-send 'hi'"
sleep = "sleep 10"

Sure thing, I'll get back to you in a week or so.

@explosion-mental wrote in https://codeberg.org/explosion-mental/wallust/issues/174#issuecomment-8600202: > @Hanker mind testing it out, I think it follows your needs, feedback is appreciated :) > > example confg: > > ```toml > [hooks] > xorg = "notify-send 'hi'" > sleep = "sleep 10" > ``` Sure thing, I'll get back to you in a week or so.

Hanker commented 2025年12月16日 12:18:43 +01:00

I just tested it out, and I'm glad to report that it works great. It also works much faster than using a script too, which I really appreciate. Excellent work and thank you for implementing this feature! All that is needed now is a release.

I just tested it out, and I'm glad to report that it works great. It also works much faster than using a script too, which I really appreciate. Excellent work and thank you for implementing this feature! All that is needed now is a release.

vaskark commented 2026年01月10日 01:00:02 +01:00

Okay. This seems to be a lot better than the script I had to write. Is there any documentation yet?

Okay. This seems to be a lot better than the script I had to write. Is there any documentation yet?

explosion-mental commented 2026年04月18日 22:10:29 +02:00

As a side note, on v4-alpha i've added templated_hooks, which just parsers the command strings into minijinja, which let's you use all the template variables for scripting. So you could do something like

[templated_hooks]
aww = "aww img {{wallpaper}}"

or more complicated things like

notify = "notify-send 'wallust' 'Applied scheme for {{ wallpaper | basename }}' --icon {{ wallpaper }}"

or some hyprland on the fly configs

borders = """
hyprctl keyword general:col.active_border 'rgba({{ color1 | replace('#', '') }}ff) rgba({{ color4 | replace('#', '') }}ff) 45deg'
"""

As a side note, on v4-alpha i've added templated_hooks, which just parsers the command strings into minijinja, which let's you use all the template variables for scripting. So you could do something like ```toml [templated_hooks] aww = "aww img {{wallpaper}}" ``` or more complicated things like ``` notify = "notify-send 'wallust' 'Applied scheme for {{ wallpaper | basename }}' --icon {{ wallpaper }}" ``` or some hyprland on the fly configs ``` borders = """ hyprctl keyword general:col.active_border 'rgba({{ color1 | replace('#', '') }}ff) rgba({{ color4 | replace('#', '') }}ff) 45deg' """ ```

Hanker commented 2026年04月19日 13:11:29 +02:00

That's awesome! The templated hooks are really useful for people who do dynamic configurations.

That's awesome! The templated hooks are really useful for people who do dynamic configurations.

osamaaj03 commented 2026年07月03日 21:44:12 +02:00

emplated_hooks, which just parsers the command strings into minijinja, which let's you use all the template variables for scripting.

this is the only feature keeping me from switching to wallust T-T. Ik I can build v4 from source but is it going to be released anytime soon?

thx for all the hard work <3 I just like the way pywal handles changing wallpapers and this is the closest thing to it

> emplated_hooks, which just parsers the command strings into minijinja, which let's you use all the template variables for scripting. this is the only feature keeping me from switching to wallust T-T. Ik I can build v4 from source but is it going to be released anytime soon? thx for all the hard work <3 I just like the way pywal handles changing wallpapers and this is the closest thing to it