Hey everyone!

I’m Soumalya, a developer interested in Linux and systems programming. I’ve been working on Wallr, a wallpaper engine for Wayland written in Rust, and wanted to share it here to get feedback from other people in the open-source community.

I started building it partly to learn more about Rust, GPU rendering, and how Wayland works under the hood. It’s grown quite a bit since then.

Wallr supports static images, GIFs, and video wallpapers. It also has 11 transition effects, per-monitor wallpaper settings, directory watching, and optional integrations with Matugen, Wallust, and Pywal.

Under the hood, it uses wgpu for rendering, with a background daemon that communicates with the CLI over a Unix socket. Video playback uses FFmpeg, with hardware decoding where supported. I’ve also included a benchmark script to compare Wallr with awww, although I’d like to test it across more hardware and compositors before drawing broad conclusions about performance.

It currently targets Hyprland, Sway, niri, and compatible KDE Plasma 6 setups. GNOME/Mutter isn’t supported at the moment.

For transparency, I used AI assistance during development to make my workflow easier. I’m continuing to work on the project, test it, and improve the implementation.

Source code and installation instructions: https://github.com/programmersd21/wallr

I’d appreciate feedback on the code, architecture, compatibility, or anything that could be improved. If you use another Wayland wallpaper tool, I’d also be interested in hearing what you like about it and what you think could be done differently.

Thanks for reading!

  • TheDarkQuark@lemmy.world
    27·
    2 days ago

    Ngl, the recent influx of AI-generated projects is slightly unnerving. While I don’t know the extent of your technical expertise, programmersd21, I’ve noticed many vibe-coded projects pop up, where the maintainer doesn’t actually understand their own codebase. All the philosophical arguments against AI aside, this paradigm might introduce severe security and maintainability flaws (I do not know to what extent this is applicable to this particular project).

    I am not an expert in Rust. But, skimming 2 random files in under 5 minutes revealed code that I wouldn’t let pass a review:

    1. https://github.com/programmersd21/wallr/blob/72e10a02ae9fdd65ba2f5a440f45906d0fffc6a4/wallr-core/src/wallpaper/mod.rs#L156

    This function called apply_wallpaper doesn’t apply a wallpaper. Instead it checks if the file exists, and logs stating it will apply otherwise.

    1. https://github.com/programmersd21/wallr/blob/72e10a02ae9fdd65ba2f5a440f45906d0fffc6a4/wallr-core/src/video/gpu.rs#L37

    This file contains the same adapter enumeration logic, but it is implemented differently across the detect_adapters and select_adapter functions.

    Also,

    ~/wallr $ rg detect_adapter
wallr-core/src/video/mod.rs
12:pub use gpu::{GpuSelection, detect_adapters, select_adapter};

wallr-core/src/video/gpu.rs
35:pub async fn detect_adapters(instance: &wgpu::Instance) -> Vec<AdapterInfo> {

    I do not know Rust, but this looks like dead code to me (these are the only two mentions of that functions; commit 72e10a02 btw). Please correct me if I’m wrong.

    If my assessment above is incorrect due to me misunderstanding the code, I retract my statement towards this project. My concerns still exist though. Perhaps it’s truly time to stop writing code that is maintainable by humans. ¯\(ツ)/¯