This was really creepy stuff. Last updated in April, 2006 to work with
kernels > 2.6.12. I consider this "fobar" (fscking obsolete beyond all
recognition) and doubt anyone still uses this. If you do, blame me. :)
This patch ought to be small and simple ...
The reason why it's not is me wanting the entropy data out of struct
information. This means update_entropy() can not be used anymore, as it
uses this globally available object.
The solution I am presenting here is quite messy regarding header
includes. Hopefully this will go away soon as I plan on creating some
sort of "OS library" containing all OS specific routines and defining
macros for easier capability checking in the non-specific code. This on
the other hand means we'll need "wrappers" around OS specific objects,
but that's not as bad as it seems - having non-specific text objects
only will definitely clean up the code, and capabilities can be checked
where they should be.
When dropping the ifblock field of struct text_object, I short-sightedly
reused the sub field for holding the pointer to the matching else/endif.
This however doesn't work for objects parsing their own object list, as
they need the sub field for themselfs.
Since we have it, simply reuse the special_data field instead and hope
there won't ever be an object which is both special and ifblock. ;)
This is more or less a temporary fix to restore the former behaviour. In
the long term objects will define a max value, which will be of use for
all kinds of meters.
The field totalmem was formerly used to hold the percentage of used mem
by a process. So at update time, the field info.memmax was being
addressed, which is potentially being updated at the same time, As all
updating routines potentially run in parallel. Though there is an
(quite) easy fix for this: calculate the percentage upon object
printing. This works because conky synchronises all update routines
right before printing the result. (To omit locking on it's own.)
