Another approach is to create a window at desktop level. It can even display a web page with a system web view — you probably want to opt the window out of receiving mouse events, too, to avoid interfering with drag selection on the Desktop.
I do that at home with a local HTML file to randomly generate a desktop background at startup, and I’ve tried dynamic content (like a countdown clock). Code here: https://github.com/s4y/Dash
But for an app like this, you could do native, animated transitions, and avoid touching the desktop background settings.
Edit: you could even create a smaller interactive window (also at desktop level) with a link to the source, a button to advance to the next wallpaper…
Similar, but targeted more at desktop widgets is Ubersicht [0]. It provides a transparent, desktop-level browser window that lets you load and display widgets that get their input from CLI commands.
I recently looked into doing this for my Windows laptop, but found that it halved the battery life. Is this also a problem with running stuff like this on Macs?
Heh it's incredible hearing about someone _trying_ to do this one Windows (and Mac) - I have very vivid memories of Active Desktop on Windows 98 that let you set an HTML page as your 'wallpaper'/on your desktop https://en.wikipedia.org/wiki/Active_Desktop
I remember that some system crashes would cause it to disable itself, with a hyperlink to reenable it. I also remember being obsessed with converting movie clips into animated gifs, and setting those as my background.
Negligible energy consumption. I wrote a desktop timelapse wallpaper app for Mac that creates a below-the-desktop window containing a movie player and then plays the movie stretched over 24 hrs. Energy impact was small, something like 0.1 in Activity Monitor.
If your app/web page isn’t doing work in the background and doesn’t receive mouse events, the energy impact should be close to nil — it should sit solidly at 0.0% CPU usage in Activity Monitor, else something isn’t right.
Neat! Do you know if this works well across Spaces? I went with the wallpaper approach because I figured it was likely to be the least error-prone, especially across OS updates.
I'd point out, however, that when I first made Artpip (https://www.artpip.com/) I rendered backgrounds using a desktop level window but the performance overhead was too high when compared to just setting the backgrounds natively, so I ended up switching over to that instead. Artpip is made with Electron though, so if you do everything natively then maybe you'll see different results.
…that should give it roughly the same behavior as the system desktop window. If you want to have things like different windows for each space, that might require the brittle hacks you’re talking about :-).
By the way, I meant to say that your approach is super cool too, and the blur and shadow effects look great.
I do that at home with a local HTML file to randomly generate a desktop background at startup, and I’ve tried dynamic content (like a countdown clock). Code here: https://github.com/s4y/Dash
But for an app like this, you could do native, animated transitions, and avoid touching the desktop background settings.
Edit: you could even create a smaller interactive window (also at desktop level) with a link to the source, a button to advance to the next wallpaper…