The decision about whether to print ASCII or X11 bar is done from within
specials.c, so all those #ifdef + if () blocks can be dropped. This also
implicitly enables the ASCII bar for some bar printing objects which where
forgotten before.
Murphy hit me again: in my naive attempt to fix the clash between
ifblocks and objects parsing text objects due to the double use of the
'sub' field, I overlooked this problem with reusing the 'special_data'
field. So here comes the real thing (TM), donating ifblocks their own
field for pointing to the jump target.
The problem with the original commit was that some session-managers set
stdin to /dev/null for the processes they launch, therefore the variable
wasn't very effective.
This commit change the variable conky_user_time to user_time.
This variable has a mandatory argument, a console identifier
(eg. tty7, pts/0, etc.).
Once called, this will list how long the user for the given console has been
logged in for.
This commit also allows multiple user_time to be specified for different
consoles, as well as correctly handle a conky restart.
The bug reporter asks if it is possible to add a variable giving the "current
user time" only, since the variable user_times reports the times for ALL
logged users.
AFAIK, the only info one can gather inside conky, is the login time for the
tty connected to conky's standard input.
This commit adds support for it (it should work on any posix compliant *nix).
Note that in coherence with the definition, the variable is called
conky_user_time (for a single user stand-alone machine used as a desktop
this would be the "current" user time).
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.
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.
