-
Notifications
You must be signed in to change notification settings - Fork 13
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
#65 add ON_CHANGE_CMD to run a shell command in handle_success #162
Conversation
Can't think of a use case to run a command when vrr changes
This looks great! I test and review this on Monday. |
Looks like you might need to assert the new INFO message during the layout test: https://github.com/alex-courtis/way-displays/actions/runs/8529996247/job/23510275263?pr=162#step:6:332 |
Now we are not testing if the command actually gets executed.
Definitely works. valgrinds successfully for happy path.
Yes, there's nothing we can do about that. We'll also get multiple events for multi-stage changes e.g. mode set, then vrr, then scale. I think we can make use of that - notifications of successive changes and the fail. |
That's completely fine, you've tested the invocations. It's definitely async and works. ON_CHANGE_CMD: 'sleep 10' |
Not quite sure what you're asking, however we could add feedback so that the user has something to go with. Perhaps the ability to send a notify message like:
We could dump that text to a file like The user could set something like this to retrieve that file: ON_CHANGE_CMD: 'notify-send way-displays "$(cat ${WD_CHANGE_FILE})"'
# or
ON_CHANGE_CMD: 'notify-send way-displays "$(cat %%wd_change_file%%)"' What do you think? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking fantastic! Please:
- add to
way-displays -g
; adding it to info.c should propagate it everywhere - add CLI set and delete commands
Great potential there: CHANGE_FAILED_CMD CHANGE_CANCELLED_CMD. Let's get the success cases nailed down first. |
I meant set and delete via the cli. Regarding the suggestion about something like a I think that would be great and I would be down to implement that. |
Alright I agree. |
Many thanks for the updates! I'll review them tomorrow or the day after. FYI my availability for this project is Mon-Tue only. |
Very sensible. This change is complete and can be merged. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looking good, works.
- simplify spawn
- add help / man
Do you want me to push changes for help / man?
- only fork once - rename from spawn_async to spawn_sh_cmd
Thanks for the review.
Did that as well. Let me know if |
That works well - it's really clear what the user can execute. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is looking fantastic! I'm excited for all the opportunities this opens up.
Let's get that last child bit in and we're good to go.
We can release 1.11 and update the wiki, unless you'd prefer to add something else first.
Thanks to dwm :)
Sounds good! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Works beautifully - immediate spawn, no zombies, no complaints from valgrind.
Many thanks for your contribution! Hopefully we can work together on more such functionality #164
Woohoo! Thanks for working on this @PaideiaDilemma ; and for your consideration @alex-courtis ! |
Thank you... I added a complex command: https://github.com/alex-courtis/way-displays/blob/master/examples/cfg.yaml#L70 |
Hi!
This tries to implement a configuration that allows users to execute an arbitrary command when display configurations change. The command gets executed in
handle_success
, so when thesucceeded
event gets fired and is processed by way-displays. This is also how kanshi implements it.Here are some things to discuss:
The test uses the filesystem because I could not come up with another good solution to check command execution.spawn_async
is not tested at all, because it is hard to test. Is that fine?Additional note for hyprland:
Hyprland currently does not play well and way-displays needs to handle multiple redundant events, so the command might get executed a few times on a change. I might look into that when I have time. Only gets executed once on sway.
Havn't tried other compositors, but that's why I added the note in
cfg.yaml
.