Xsnow: what does it do?
Xsnow is an application that animates snowfall, Santa and some scenery on your desktop. It is NOT a kind of screen saver: snow is falling, Santa rides his sleigh with reindeer while you are using your system. Xsnow runs on most varieties of Linux, and probably on other Unix systems as well.
In 1984, my colleague Rick Jansen created an application for the Apple Macintosh computer, called, if I remember well: snow. This application animated snow on the desktop, including snowflakes, fallen snow and even Santa flying through the air.
Later on Rick acquired a real system, a Silicon Graphics workstation, and soon he produced a version of snow that could run in an X11 environment: xsnow, first released in 1993. This version shows fallen snow not only at the bottom if the desktop, but also on windows. (Maybe the Macintosh version did this also, difficult to verify now). More information, including links to other implementations, is available on Wikipedia. Rick is still working on snow for the Mac, the program is baptized iSnow. It appears that much eye candy has been added in due time. One could almost be temped to acquire an Apple system to run iSnow! And then, there is even a shareware version, winsnow, that runs on MS Windows.
It seems that xsnow was received well by the community, despite the fact that is was not released in the Public Domain :-(. When you look for xsnow on the www, you will find complaints that xsnow does not function well on modern desktops like Gnome and KDE. It seems that there was a solution for KDE, but I found that that solution does not works any more. In Debian, under non-free, xsnow is still offered (version 1.42), but it only works on 'simple' window managers like FVWM that use the root window to place the windows. When you start this version of xsnow, in general you see nothing, because it is snowing behind the desktop.
Towards Gnome xsnow
I waited some years for somebody to solve the snowing-but-not-visible issue, but alas, no solution was provided. So, after almost finishing my findent project, I decided to have a look, in November or December 2018. Before Christmas 2018, I had something running. I let Rick know, and he was very pleased, he said. Now I am polishing xsnow further and hope to have a dependable version months before Christmas 2019.
Xsnow has old roots and is adapting to new environments, visible in the code, which is a good thing for an application like xsnow. For example, there is no convention whatsoever for the naming of variables and functions. Something like 'windonfallensnow' can be spelled like: 'windonfallensnow', 'wind_on_fallen_snow', 'WindOnFallenSnow', WOFS and so on. The language used is C, (not C++ as would be the obvious choice now (no, not Python or Ruby: we really need some performance)), with many global variables, sometimes with not very helpful names. The choice whether a function and accompanying header files are placed is separate files or in xsnow.c, is based on the moment of the day, or the flipping of a coin. Xsnow-1.42 hardly used floating point aritmetic, xsnow-2.0 uses a mix of floating point and integer arithmetic, floating point gradually taking over. The documentation contains references to systems that are extinct for many years, but description of new flags has been noted to creep in. Xsnow's genes show traces of findent, and even of some Hitchhikers Guide. The genes for 'toon.h' are almost gone, there are at this moment better ways to find the window to snow in. The program became aware of the fact the Santa's sleigh is pulled by 8 reindeers: Dasher, Dancer, Prancer, Vixen, Comet, Cupid, Dunder and Blixem. Later on, Rudolf could be added. It seems that some of the pixmaps are evolving in that direction.
The original xsnow-1.42 has an more ore less ad-hoc timing mechanism. The program offers many flags to tweak the speed of Santa, the speed of snow and the like. Xsnow-2.0 has a more straight forward timing mechanism, in principle, every speed is defined in pixels/second.
The updating and drawing of Santa are decoupled, so the refreshing rate of Santa does not affect His speed.
Fallen snow (bottom and on windows) is nice in xsnow-1.42, but after running for some time, the visualization of fallen snow is not realistic. Therefore I use now a complete new strategy for the handling of fallen snow.
The handling of wind is changed in xsnow-2.0: it is now more or less windy all the time, but the original code from xsnow-1.42 is still used to experience more dramatic wind effects. The algorithm for the sensibility to wind of Santa and snow has been changed: The velocities of Santa and snow are changed by the wind.
In xsnow-1.42 an fixed-length array was used to hold the snow flakes. In xsnow-2.0, the flakes are in a double-linked list. This makes it possible to add snow flakes at random times, for example when converting fallen snow to snow flakes. Furthermore, the amount of snow is now determined by the rate the flakes are produced and removed. The production rate is given in flakes per second per pixel (i.e. the width of the window measured in pixels). This has the effect that, in a steady state situation, a larger window shows more flakes than a smaller one.
meteorites: On a gnome-like desktop, these are drawn and removed as described above. In other windows, the drawing and removing are done using GXxor.
stars: they are drawn in the air, are persistent, but change colour now and then, giving the illusion of twinkling. Stars try to be visible through fallen snow, this is not as it should be. Working on it.
xsnow -treetype nnnyou can choose what kind of scenery you want to see (Thanks to Carla Vermin-Anderson). More tree types are coming. Items are placed randomly, in contrast with xsnow-1.42. Care is taken that falling snow flakes are not interfering with the scenery, using Regions.
disappearing fallen snow: when a window is destroyed, the fallen snow on it is converted to snowflakes. Nice!
Santa now plows away the fallen snow He encounters.
Before version 2.10, xsnow refused to run on Wayland (that is the proposed successor of X11 and is the default on recent Debian-derived installations). I was prepared for major code changes in xsnow, but, after lots of googling, I found a solution, at least for xsnow: simply set the environment variable GDK_BACKEND=x11. So, before the gtk environment is initialized (using gtk_init()), xsnow sets (using setenv()) that variable to the desired value. Of course, the official GDK documentation has something about the issue . It could very well be that things work thanks to XWayland, I really don't know very much about X11 and Wayland. In Wayland, applications have only a restricted control over the windows that are not owned by the application. So, xsnow cannot snow in other windows. But for many of the windows the information about the where belongings are available to xsnow. For example, xsnow is snowing on the windows of firefox, gimp, gvim, xsnow, xterm, xclock and xcalc, but not on the windows of aislerioth, gedit, nautilus and gnome-terminal.
In KDE xsnow-2.0 works. You can specify a monochrome background if there are problems.
In FVWM there are no problems.
In LXDE and XFCE there are no problems.
In Mint xsnow works the same as in Gnome.
In Raspbian (Raspberry pi's default desktop) xsnow runs by detecting the desktop is LXDE.
In FVWM, xsnow works as the vintage one: simply painting on the root window.
In LXDE, xsnow detects this environment and will snow on the window with the name 'pcmanfm'.
In XFCE, xsnow detects this environment and will snow on the window with the name 'Desktop'.
In more advanced desktops (GNOME, KDE, ...) xsnow creates a transparent click-through window to paint on. This window can be placed below all other windows, or before.
Xsnow-2.0 can snow in arbitrary windows, you can choose one (using
xsnow -xwininfo), or you can specify a window-id (using
xsnow -id window-id). Using the flag '-xwininfo', it often happens that it is snowing (again!) behind the window you seem to select. I am working on this issue. Using the flag '-xwininfo' turns exposures on, unless you specify '-noexposures'.
The location of the top of the windows, including the decorations, is a known issue on the web. I found a solution for this issue: see the code in wmctrl.c (from the xsnow tarball). And, by looking at the code of the programs wmctrl and xwininfo and xprop, I was able to incorporate the things I need in xsnow with respect to choosing a window, locate a window etc.
In FVWM-like environments, xsnow starts on all desktops. Not so in Gnome and KDE. Among the downloads I included shell scripts 'startondesktop' and 'startonalldesktops' that you can try to start xsnow on (a subset of) all desktops. On my system it works (Gnome & KDE). Hopefully, the next major release of xsnow will have this feature built-in.
Graphical front end
My agenda showed some free hours on Kings-day (27 April 2019), which gave me the opportunity
to finish the graphical front end. The front end is written using GTK3 and Glade as a designer tool.
Details are in
ui.c, ui.h, ui.glade, main.c: do_uicheck().
Since version 2.0~pre5, xsnow is equipped with the standard './configure; make; sudo make install' suite. Even 'make distcheck' works'.
If you are running some kind of Debian (Ubuntu, Mint, ...) system and your hardware is of type amd64:
On the downloads page, you find a debian package. Download and
sudo apt install ./xsnow_2.0.15-1_amd64.deb
and you are done. Xsnow should be available under 'games'.
In general, installing is done like this:
- resolve the following dependencies:
- In debian-like environments (including Raspbian):
sudo apt install libx11-dev libxpm-dev libxt-dev pkg-config libxml2-dev libgtk-3-dev
- In other environments (Suse, Redhat, ...): I am sure you know how to install these packages ;-)
- Download the file xsnow-2.0.15.tar.gz (see the Downloads page)
umask 022 tar xf xsnow-2.0.15.tar.gz cd xsnow-2.0.15 ./configure make sudo make install
- Xsnow should now be installed as
Xsnow and X11 and GTK
Xsnow is based on X11, the graphical frontend is written using GTK-3. I tried to create a GTK-3-only version of xsnow, and encountered the following problems:
- Performance: using GTK, the process xsnow and Xorg use both more than half a cpu. With xsnow-x11, only Xorg is very busy, xsnow itself uses a few percent.
- Getting information about other windows is not really possible, it seems. So xsnow would not be able to snow on windows.
For now, I abandoned the xsnow-gtk project, maybe inh GTK-4 or GTK-5 there will be more possibilities...
Xsnow on Apple IOS
There will never be a version of xsnow for Apple IOS, because there is already a very good nephew of xsnow available for Apple IOS. Search for 'isnow' in the Apple store. I guess this is enough explanation for Apple IOS users. I have no access to such a system, so I cannot test. BTW: isnow is written by Rick Jansen, so quality is guaranteed.
Xsnow on MS Windows
I am certainly not planning to port xsnow to windows. Once upon a time there was 'winsnow' (also created by Rick Jansen), but I am unaware of the status. There is some info here.