Previously, a green hint line was drawn on the CPU window for each
multiple of 1. This meant as the load average approached 40 (the
height of the window), the window would gradually fill up entirely
with green.
To get around this, we switch to a yellow hint line for each
multiple of 10 once the load passes 10. And then a red hint line
for each multiple of 100 once the load passes 100.
This fixes Debian bug #894801, reported by Pedro Gimeno
<debian.bts@personal.formauri.es>.
The system load monitor displays green hint lines at every 100 units once
load average rises above 100.
Previously, the vertical position of these lines was computed before
each and every pixel was drawn. But since the horizontal position
isn't needed for this computation, we move it up a level to the
outer for loop.
Previously, we looped through the history and added 100 whenever we found
a larger value. This has a number of problems. In particular,
* We get a maximum possible value of 5500 (100 * the number of values in
the history). It is certainly possible to have a system load north of
this on modern systems.
* If the system load in history were to jump by more than 100 in a single
step, then we wouldn't be adding enough. For example, suppose the
system load in history is 175, and our height was previously computed
to be 200. Suppose the next value in history is 320. We would add
100 to get a new height of 300, which isn't sufficient to display the
320.
The fix is simple -- replace the if statement with a while loop, i.e.,
continue adding 100 until we get a height that fits our value.
Patch by David Johnson <davijoh3@cisco.com> to fix Debian bug #816872 [1]:
> wmbattery appears to have a memory leak. When invoked with "wmbattery -w 2"
> it is leaking approx 350KB/minute on my system. Eventually it runs out of
> memory and is killed by kernel.
...
> I've concluded libupower-glib is just super leaky. The below patch
> moves the upower API calls into a child process that doesn't exist for
> long to keep the leaks out of the main process.
> Tested against stretch versions, looks good.
[1] https://bugs.debian.org/816872
In addition to accounting for the various changes in the new version, we
also rename from the deprecated 1x section to just 1 and get the
current version number from autoconf.
Now that we use libdockapp's --windowed option to allow users to choose
whether to run fookb as a dockapp or as a normal windowed application at
runtime, the --enable-wmaker option compile time option did very little.
In particular, it used a config file in ~/GNUstep/Defaults and it printed
a warning message when users used large icon files.
We now use the ~/.fookb config file in all instances and always print the
warning message.
In addition to the obvious simplification to the code by removing all the
window creation stuff, this also allows us to let users pick whether they
want to run fookb as a dockapp or as a normal windowed application at
runtime using libdockapp's --windowed command line option. Previously,
this was done during build using configure's --enable-wmaker option.
Previously, we would try and read the width and height of images read from
an XPM file *before* doing any error handling to determine whether we
successfully read the file in the first place. If there had been an error,
then there would be a segfault.
libdockapp supports shaped dockapps with the DASetShape() function, but this
function requires as input a bitmap. Previously, there was no support for
creating such a bitmap from XBM data without using Xlib directly.
We add two functions, DAMakeShapeFromData(), which is a wrapper around
XCreateBitmapFromData and allows developers to #include XBM data, and
DAMakeShapeFromFile(), which is a wrapper around XReadBitmapfile and
lets developers specify the path to an XBM file.
Some dockapps may want to handle command line options themselves, so we
make this function optional.
Previously, if this function was skipped, then a segfault would result when
trying to access the _daContext global while first creating the dockapp
window.
Now we check if _daContext has been initialized first, and if not, we
initialize it.
