Notice:

Due to microsoft's policy on AI, the source can be found on codeberg or gitlab as Wayvy.

Dependencies:

Required:

• mpvpaper
• mpv
• rustup

Optional:

• dbus/busctl
• systemd
• pywal or walrs

Theming:

With the "theming" feature enabled and the appropriate fields filled in the config, pywall or walrs may be used to automatically apply theming based on the current wallpaper.
This feature is EXPERIMENTAL and has LIMITED SUPPORT (super primitive at the moment). Further integration is planned.\

Walrs

As of writing, the status of walrs is uncertain. It was updated recently (2 months ago as of writing), however the website linked for documentation and used as the source for both AUR packages has been unreachable every time I have attempted to reach it. As such I have created a fork that I intend to maintain at https://github.com/Jsbarkleygriggs/walrs, and an AUR package (walrs-maintained) until further notice.
To use Wayvy with Walrs add

[themer]
backend = "walrs"
theme_reload = true

to your config.toml. "theme_reload" toggles the calling of walrs reload scripts. See man walrs for more information.

Pywall

As of writing, the use of pywall is theoretically supported but untested. Have fun. To use Wayvy with Pywall add

[themer]
backend = "pywall"
theme_reload = false

Roadmap:

Roadmap in development, please standby.

Installation:

Wayvy is packaged on the AUR. Gentoo and NixOS packaging are in progress. Otherwise, you know the drill:

Makefile

git clone https://codeberg.org/jsbarkleygriggs/wayvy.git
cd wayvy
make FEATURES="dbus" install

Feature flags include "dbus" and "theming" which enable dbus and the use of pywall/walrs respectively.
If you wish to make with full features just run

make install

Just know that "theming" is in the early stages of development.

Manual installation

git clone https://codeberg.org/jsbarkleygriggs/wayvy.git
cd wayvy
cargo build --release --features=dbus

Feature flags include "dbus" and "theming" which enable dbus and the use of pywall/walrs respectively.

If running as a systemd service:

cp ./target/release/wayvy ~/.local/bin/
cp ./packaging/wayvy.service ~/.config/systemd/user/
systemctl --user daemon-reload
systemctl --user enable --now wayvy.service

Usage:

If running with systemd:

systemctl --user status wayvy.service
journalctl --user -u wayvy.service -e

If using dbus:

At the moment the interface paths are fixed, this is unlikely to change unless requested.\

To see status and available commands:

busctl --user introspect com.wayvy /com/wayvy com.wayvy

Commands are executed with:

busctl --user call com.wayvy /com/wayvy com.wayvy <command>

As of writing, the available commands are as follows:

busctl --user call com.wayvy /com/wayvy com.wayvy Next
busctl --user call com.wayvy /com/wayvy com.wayvy Pause
busctl --user call com.wayvy /com/wayvy com.wayvy Resume
busctl --user call com.wayvy /com/wayvy com.wayvy TogglePause
busctl --user call com.wayvy /com/wayvy com.wayvy ReloadConfig
busctl --user call com.wayvy /com/wayvy com.wayvy ChangeMode s <ModeName>

Wayvy is intended for use with an external controller such as an applet or runner.

An example anyrun plugin is provided at https://codeberg.org/jsbarkleygriggs/anyrun-wayvy.git\

If not using dbus:

Direct cli support is limited at the moment but support is planned. Pull requests welcome.

Demos:

*Some of these demos may be sped up

Config files can be hot reloaded:

Demo of color changes with gifs, livestreems, mode changes, and remote files:

Configuration:

Wayvy uses a minimum of two configuration files: config.toml and .toml (as defined in config.toml). .toml is where your wallpapers will be specified, a specific format is required

Files are grouped together into "profiles" and "profiles" are grouped into "modes". There is one mode per mode-file, and mode-files may be specified in config.toml

Each profile can be optionally associated with a weight and a set of flags. The weight determines how frequent the files in that profile appear, and the flags are applied to all files in a profile. An arbitrary number of profiles may be created containing an arbitrary number of files. Likewise an arbitrary number of mode-files may be created to suit your needs.

Example configuration and mode files can be found in wayvy/packaging/

For flag and file format specifics see mpv documentation.

If using systemd:

Configuration file and mode files should be located in ~/.config/wayvy/

Without systemd:

Config directory can be specified with the WAYVY_CONFIG_DIR environment variable.

Troubleshooting:

Try doing a sigkill on mpvpaper, wayvy should start it back up without issue. Regardless, please send me a log
note that at the moment it is possible that requesting "next wallpaper" will result in the current paper being reselected. THIS IS BY DESIGN. If you want it changed, start and issue or smth, if peple want it different, I can make a setting for it. Set RUST_LOG=debug or RUST_LOG=trace to get better logging.
If running with systemd, you can update the log level in <systemd_user_dir>/wayvy.service

Why Wayvy?:

There are certain advantages to it over alternatives, namely per-file MPV flag specification. This can be useful in preprocessing web based images, for example when pulling from a weather satellite and applying a crop or rotation. I will grant you this is niche, but I wanted it so I built it. Could this have been a bash script? Yes! That's how it started, but MPV is ... finicky and I found myself desiring more robust error and crash handling. So here we are. Cheers.

If you are interested, here is the current feature list, though it is not that different from alternatives:

• Dbus integration
• Systemd integration
• Anyrun plugin (prototype)
• Theming integration with pywall or walrs (does not work for livestreems)
• Support for gifs, Videos, livestreams
• Per wallpaper mpv flags
• Toml config (reloadable via ipc)
• Toml modes (reloadable via ipc)
• User defined modes

Project Disclaimer:

I am a physics student, this is one of my many hobbies that I do not have time for (in case you couldn't tell by my complete lack of professionalism here). I do, however, intend to maintain this. But do not expect quick response times.\

I made this as a means of learning rust, some of the decisions are a product of trying something just to learn it, other choices may directly reflect my inexperience, please have patience.

Pull requests are more than welcome. I may accept feature requests, but in general, unless the problem of implementation seems like an interesting puzzle, I will re-delegate the task of implementation to you.\

I hope someone other than me ends up enjoying this...but heck, that was never the point.

License

MPL 2.0