1. 9
  1.  

  2. 8

    The timed (or dynamic) wallpapers in macOS Mojave also use the azimuth of the sun to try to mimic the day/night cycle you see outside on your computer.

    Marcin Czachurski spent a lot of time (1, 2 and 3) reverse engineering the file format – it’s based on an HEIC container, I think.

    In my experience, it’s not all that accurate – the sun sets much faster outside than on my computer.

    1. 2

      That’s interesting. I guess the ultimate in wallpapers would be to raytrace the desktop wallpaper with accurate lighting as Earth rotates and revolves around the sun.

      1. 4

        I remember using xplanet to do something like that like 10 years ago. It would set my X background to a map with accurate day and night indication. I wish there was something like it for modern high resolution screens.

        1. 3

          I used xplanet to show me a view of Mars. I can’t remember whether it was rotating in realtime or not… I believe it was. Fascinating piece of software, which I don’t think ever made it off Linux.

          1. 3

            I’d forgotten all about xplanet. Thanks for that trip down amnesia lane!

          2. 3

            This sounds like a job for WebAssembly.

            I’m only half-joking. It sounds like a method that could work, compiling one of those business card raytracers into a program that draws your wallpaper without being able to do arbitrary I/O. Better than Windows .scr screensavers, which are literally just executable complete with the ability to do arbitrary system I/O (so many old viruses pretended to be screensavers…)

            1. 1

              There is a project offering 3D animated wallpapers, named livewallpaper.

              Check out the livewallpaper package if you are using Arch Linux.

        2. 4
          <starttime>
            <year>2011</year>
            <month>11</month>
            <day>24</day>
            <hour>7</hour>
            <minute>00</minute>
            <second>00</second>
          </starttime>
          

          I wonder what the justification was for that format? It’s hard to read for humans, hard to parse by computers (vs strptime), and ~5 times more characters than the ISO 8601 format used by many XML schemas.

          1. 1

            Yes, I was a bit surprised about that too. Especially since that time is used as a base value, and the elements needs to be parsed in the correct order for seconds to be added to the start time, to get the correct timing. Also, only the hour and minute seems to matter.

            1. 1

              I think your link was meant to go to duration, not dateTime.

              1. 1

                No, I think datetime was correct. If “starttime” is a duration then it’s even worse than I thought.

                But the duration for each wallpaper comes later in the xml file, and seems reasonable:

                <transition type="overlay">
                  <duration>14400.0</duration>
                  <from>/usr/share/backgrounds/gnome/mojave/mojave_dynamic-0100.jpg</from>
                  <to>/usr/share/backgrounds/gnome/mojave/mojave_dynamic-0500.jpg</to>
                </transition>
                
                1. 1

                  No, I think datetime was correct. If “starttime” is a duration then it’s even worse than I thought.

                  I meant is that you could encode startTime and endTime as a duration, like this:

                  <pictures>
                    <picture duration="8H--16H">picture.jpg</picture>
                    ...
                  </pictures>
                  

                  Actually, I think it would be nice to specify startTime as a date, such that advanced implementations can calculate and correct for different latitudes and seasons.

                  Thinking even more about it, I’d probably go the complete opposite way: I think most of the time information in the file format is unnecessary – remove all the time stuff from the format and only keep the transitions. Using the pictures’ EXIF data for the time it was shot is the best way to go.

                  1. 1

                    Using the EXIF data is a nice idea for JPEG images, but there may be image formats that does not support this.

            2. 2

              I think for simulating day and night change HDR processing might be useful. Blending 8-bit-deep jpegs is somewhat limited for this.

              Even single HDR photo taken at evening sometimes might be enough to make it look like it’s overcast at day time.

              1. 2

                That’s true, having support for HDR photos would be an interesting feature. But it’s a very nice effect in the Mojave timed wallpaper when the stars gradually appear as night approaches, and this could not be achieved with HDR without making very unusual modifications to the HDR images.

                Also, some people just want to switch to the next image in their wallpaper collection.

              2. 2

                Good work on trying to write a readable spec! :)

                Few minor nits:

                • The final example would benefit from showing how that format uses transitions, as none seem to be specified.
                • The filename should be quoted and escaped, otherwise you’ll get weird results when writing a parser and presented with malicious inputs (what if I name my wallpaper after a valid substring of a wallpaper definition entry?).
                • Consider writing a regex with named capture groups to make absolutely clear the intent of the line format. As a bonus, this will shave a little annoyance off of implementors’ lives.

                If you want, maybe as practice some Lobsters here could do some spec golfing and show other ways of conveying the same information.

                1. 1

                  Hey, thanks for the feedback! I’m always open to constructive criticism and spec golfing.

                  I will add a better example for how the format uses transitions.

                  About the filename quoting: I fail to see how it would go wrong. The parser looks for a line that starts with @, then for a certain number of colons : and then picks up whatever is there, until the end of the line. Do you have an example?

                  A named capture group is a good suggestion. I was also thinking that something like python-style prefix{{ word }}postfix could be clearer than prefix%spostfix, but both styles are pretty conventional.

                  1. 1

                    Filename quoting: If paths with newline is the only thing that could confuse the parser, you only need a way to escape that (as sha1sum does), or disallow such paths. If Windows line endings are supported, same for carriage return.

                    Same with non-UTF-8 paths – you can choose to represent them somehow or not support them.

                    1. 1

                      Thanks, but I still don’t get it. Is quoting needed only to be able to support newlines in filenames? Should that even be supported? :)

                      1. 1

                        Maybe not, but you know me, I’m the quoting ambassador ;-)

                        I edited my answer with more to the checklist. You might just explicitly not support these…

                2. 1

                  For those who have never heard of this and can only guess - what are timed wallpapers? Is this only about changing them every few hours? days? Or more like multiple times per second like animated gifs?

                  From other comments I see Mojave seems to have them? (I’m not a Mac user). Also some quick googling didn’t really enlighten me if I should have heard about this if it has a common understanding.

                  1. 1

                    It’s usually about changing the wallpaper every few hours, but with cross-fading from the previous image to the next, which is a nice effect.

                    Here’s a short video of the Mojave timed wallpaper: https://imgur.com/a/fP2DplN (link from https://github.com/japamax/gnome-mojave-timed-wallpaper).

                    1. 1

                      Awesome, thanks - apparently no one I know uses it or found it cool enough to rave about it.

                      I was just a bit puzzled because changing wallpapers at random has been a solved problem for 20 years :)

                  2. 1

                    I always thought about having an opengl (or maybe vulkan now) enabled wallpaper engine, utilising GLSL and the like. Perhaps it would only turn on when you have no big window in the way. Not exactly timed, but, contextual?

                    Just imagine your favourite terminal window on top of this background:

                    https://www.shadertoy.com/view/XslGRr

                    1. 1

                      Changing the desktop wallpaper takes 0.2 seconds under Xfce4 on my computer. This would give animations a frame rate of no more than 5 FPS. It is possible, but you would not get a smooth animation this way, and it would possibly tax the system.

                      A more feasible approach could be to run a 3D application in a window that is behind the other windows, in the same way as some window managers solves having a desktop with icons. This would give smoother animations, but then you would have this running in the background at all times, quite possibly making fans spin and making use of other applications noticeably slower.

                      Having a live wallpaper running only if > 80% of the window was visible could be a possible solution, but I have not seen anyone implement this yet.