wip: wpaperctl set MONITOR NEW_WP_PATH

[alphastrata]

Heya,

I have a tool that pulls new images for me every 10 minutes from a server, I don't like my current solution which is a shell script modifying the ~./config...'s path on a per monitor basis.
I think it'd be nice to be able to do something like:
wpaperctl set <MONITOR> <NEW_WALLPAPER_PATH> kinda thing..

I've gotten most of the way there in this PR, but wanted to get thoughts etc before finishing it, as I'm certainly missing something.

Also, I get:

cargo run --bin wpaperd -- -d
   Finished `dev` profile [unoptimized + debuginfo] target(s) in 0.09s
    Running `target/debug/wpaperd -d`
target/debug/wpaperd: error while loading shared libraries: libEGL.so.1: cannot open shared object file: No such file or directory

which is weird? as I'm using the included flake.

[danyspin97]

Hey @alphastrata, thank you for your PR! Actually, this is a much-needed feature that I didn't think about. A few notes, I took a look at the script that you shared, but I couldn't make out where the output is going to be. Can you please share more? I am actually curious to see if this workflow can be managed by the configuration or not, also for future references and similar use cases.

Regarding your PR, it works fine but, I have a couple of things that I think should be clarified now.

• Once the user has set up a new path, it will never go back to the previous one. Is that okay? Maybe a next --path command could be added (in a separate PR, but still good to discuss here to cover all use cases).
• What happens if there is a timer and the new path is an image instead of a directory?
• Can we change the timer and other options with the set command as well?
• Do we want to retain the options set by the user if the configuration changes?

My first idea would be having a set command that allows the user to change the configuration in all its parts, and retain it until the user call set --from-config. What do you think about it?

[danyspin97]

Regarding the error for libEGL library, can you please share more information regarding your system?

I found something similar while looking through internet:

• https://discourse.nixos.org/t/veloren-airshipper-libegl-so-not-found/18225
• wezterm: libEGL.so: libEGL.so: cannot open shared object file: No such file or directory NixOS/nixpkgs#172878

I don't know if those can help.

[alphastrata]

Re the 'script' sorry it's actually an app -- it downloads GIANT ass images(70-180MB) of the earth from a satellite every ten minutes, I've no interest in keeping all these files on disk (too big) and don't ahead of time know what's in the directory which is why I arrived here.

• Once the user has set up a new path, it will never go back to the previous one. Is that okay? -> I think so, I was imagining the explicit verb of set wallpaper to override anything that may be there already, thoughts?

• What happens if there is a timer and the new path is an image instead of a directory? -> I think that if set x is called whatever timer is running just stops? thoughts?

• Can we change the timer and other options with the set command as well? -> Maybe set x and by default it's not on a timer but if one did set x with-timer=60s it'd just change to the x than preserve the upcoming stuff that maybe in a queue?

• Do we want to retain the options set by the user if the configuration changes? -> I think not, the envisaged use ase was for files that may not live on the user's system long...

[alphastrata]

Regarding the error for libEGL library, can you please share more information regarding your system?

I found something similar while looking through internet:

* https://discourse.nixos.org/t/veloren-airshipper-libegl-so-not-found/18225

* [wezterm: libEGL.so: libEGL.so: cannot open shared object file: No such file or directory NixOS/nixpkgs#172878](https://github.com/NixOS/nixpkgs/issues/172878)

I don't know if those can help.

i'll take a look, thank you!

EDIT: nixGL cargo run --bin wpaperctl works as expected ty !

[danyspin97]

Re the 'script' sorry it's actually an app -- it downloads GIANT ass images(70-180MB) of the earth from a satellite every ten minutes, I've no interest in keeping all these files on disk (too big) and don't ahead of time know what's in the directory which is why I arrived here.

Is there a way to set a symlink to the latest directory? I.e. use path /tmp/my-new-images in the config and let the application (or application caller like the systemd service) update the link to the latest directory of newly downloaded images. I am not against adding a new method of doing this (like set), but only to get a better understanding, as I thought of your use case before and believed that a symlink would suffice.

Once the user has set up a new path, it will never go back to the previous one. Is that okay? -> I think so, I was imagining the explicit verb of set wallpaper to override anything that may be there already, thoughts?

Likewise, I agree, that would be reasonable.

What happens if there is a timer and the new path is an image instead of a directory? -> I think that if set x is called whatever timer is running just stops? thoughts?

I would still keep the timer if the new path is a directory. Then I am not sure if wpaperctl should print an error if an image is set as wallpaper and there is a duration also set. I would prefer to be more verbose about what is happening, and the user decide what to do in that case (i.e. add --timer none if they still want to proceed). I am thinking about set command as a way to change the runtime configuration, following all policies that are set for the normal one. This would also allow to save the configuration back to the config file in the future.

Can we change the timer and other options with the set command as well? -> Maybe set x and by default it's not on a timer but if one did set x with-timer=60s it'd just change to the x than preserve the upcoming stuff that maybe in a queue?

I agree as well.

[alphastrata]

Is there a way to set a symlink to the latest directory? I.e. use path /tmp/my-new-images in the config and let the application (or application caller like the systemd service) update the link to the latest directory of newly downloaded images. I am not against adding a new method of doing this (like set), but only to get a better understanding, as I thought of your use case before and believed that a symlink would suffice.

RE: Symlinks, yes this is possible, but the cleanup is a little tedious. (In a perfect world maybe we could even have an arg that just accepted raw bytes of an Image as part of an arg, to allow images downloaded etc to skip disk entirely :wink :wink)

What happens if there is a timer and the new path is an image instead of a directory? -> I think that if set x is called whatever timer is running just stops? thoughts?

RE directories:
I am not sure we should allow set this to be a directory, that sounds more like an add dir sort of command no? perhaps there are more nuances and potentially a bit of 'renaming' so the nomeclature is less confusing?

On timers/configs etc:
Perhaps any use of the set is so imperative that one would expect a pre-existing settings/config etc to be ignored entirely, much like if you start using the steering wheel (manually) when a car has cruise-control enabled, the automatic stuff is just all immediately disabled as 'the user is driving now'. I think this sort of idea was what I was chasing: to attempt to express it more explicitly: " I would like to be able to 'drive' wraperd from the output of other programs programmatically such that it becomes more composable with any linuxy tool that can spit out a valid path to an image somewhere".

[alphastrata]

Was able to put a few touches on this this arvo, to test obviously don't be already running it all so:

pkill wpaperd
pkill wpaperctl #(jic)

cargo run wpaperd

nixGL cargo run --bin wpaperctl -- set "some image.png" DP-1 #/2/3/4/ whatever

[danyspin97]

nixGL cargo run --bin wpaperctl -- set "some image.png" DP-1 #/2/3/4/ whatever

Glad to know that the issues have been fixed!

RE: Symlinks, yes this is possible, but the cleanup is a little tedious. (In a perfect world maybe we could even have an arg that just accepted raw bytes of an Image as part of an arg, to allow images downloaded etc to skip disk entirely :wink :wink)

It should be pretty easy to implement right now, the issue is that many people would like to download images using an API and it should also be configured. That requires a plugin system, and it's what I'd like to avoid currently.

I am not sure we should allow set this to be a directory, that sounds more like an add dir sort of command no? perhaps there are more nuances and potentially a bit of 'renaming' so the nomeclature is less confusing?

add dir wouldn't work, as wpaperd currently only works with with a single directory as path (more in #42). Maybe revamping the nomeclature could make it all easier.

Perhaps any use of the set is so imperative that one would expect a pre-existing settings/config etc to be ignored entirely, much like if you start using the steering wheel (manually) when a car has cruise-control enabled, the automatic stuff is just all immediately disabled as 'the user is driving now'. I think this sort of idea was what I was chasing: to attempt to express it more explicitly: " I would like to be able to 'drive' wraperd from the output of other programs programmatically such that it becomes more composable with any linuxy tool that can spit out a valid path to an image somewhere".

That makes sense, and it's actually a good idea; wpaperd would be way more programmable than now. I am thinking of set as a way to override the current settings, and with a --empty/--erase/--reset argument to behave exactly as you described. Another change needed is to start wpaperd without a valid configuration, maybe with a flag --skip-checks.

What do you think about this idea?

[alphastrata]

I think the skipping of checks etc is a great idea.

to recap is it, what it is that we want to go into this one to wrap it up (the local build I'm running of it is now serving my needs ) , I'm happy to make changes.

[danyspin97]

to recap is it, what it is that we want to go into this one to wrap it up (the local build I'm running of it is now serving my needs ) , I'm happy to make changes.

I think we need to expand set scope a bit before merging it in. Currently I am working to release 1.1 with multiple transitions support, then we can add set command in 1.2. Is it okay for you?

[alphastrata]

to recap is it, what it is that we want to go into this one to wrap it up (the local build I'm running of it is now serving my needs ) , I'm happy to make changes.

I think we need to expand set scope a bit before merging it in. Currently I am working to release 1.1 with multiple transitions support, then we can add set command in 1.2. Is it okay for you?

yeah sure -- I'm cool with using the fork tbh, but more than happy to help get it in to the next one.