The IOError happens every time I close conky's normal own window, so I
guess the situation is not as abnormal as abort() indicates. Calling
exit() instead should really suffice and give the process a chance to
clean up (by calling destructor routines for instance).
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.
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. ;)
Note that the code does not only use a pre-processor generator for
defining the print functions, but also for their prototypes. Sadly, this
generated a conflict in mboxscan.c which this patch resolves, too.
* minimise core code hooks
* drop useless exporting of private functions (and make them static)
* reorder functions in eve.c so no prototypes are needed
* drop massive header include and add double include barrier in eve.h
While testing, I found two already existing bugs:
* the variable 'a' passed to iconv_convert() needs to be passed by
reference in order to allow for the desired side effect.
* Somehow the trailing junk after an iconv_conversion to a shorter
string messes things up (and gets printed!). I couldn't exactly find
out why this happens, but setting (*p) = 0; solves this problem.
-d was broken because fork-to-background was done after the update thread creation, so the
threads ended up in the wrong process. This delays the thread creation until after the fork.
Originally, I was experiencing sporadic lockups when reading inotify_fd;
which is strange, since it is protected by select(). This should fix it
despite of the original problem.
Besides improving performance when updating stuff, we ideally have no
text object specific code in update_stuff() anymore (aside some
leftovers).
The macros in construct_text_object() have gotten a bit crazier than
they were before:
* using CALLBACK(&func) instead of an INFO_* parameter to OBJ() will
make it add the given callback to the list of callbacks to be iterated
over at each update interval.
* BEWARE: the above assumes function pointer values to be > 0!
* This implicitly fixes a bug in the code: passing 0 as INFO_* value
led to selecting INFO_MAIL (1 << 0 == 1).
* Now it would select INFO_CPU (== 0), which got unused and therefore is
not a problem at all (the 0 value should be unused in enums anyway).
This needs some more work, then we should be able to drop the whole
INFO_* enum. Then CALLBACK() can die again and with it goes the ugly
casting stuff done to distinguish callbacks from INFO_* values.
All ERR()'s are renamed to NORM_ERR() and box to mbox so that they don't
clash with things in ncurses.h .
Ncurses is enabled by default when building conky but can be disabled with
--disable-ncurses .
At the moment configure doesn't check if ncurses is actually available.
I'm adding support for ncurses so that we can make as much things as possible
that are only available in X11 also available in console in the future.
The alias option was broken by fb8ccd7a05,
and it seems like trying to make it work again will only result in
breakage for env var substitution anyway.
Added conky_set_update_interval() API call, which allows you to change
Conky's update interval from a Lua script. Added the 'conky_info' table
to global Lua context, which still needs populating with stuff (right
now it only contains the current update interval and the system uptime).
Conky now kills the program when it should start the next update, this makes using things like tail with
the -f option possible in a \$exec.
I am not pushing this to 1.7.2 because this is a pretty big change in the code and it is not really
a bugfix but more a usability-problem-fix (if that term would exist).
