DragonFlyBSD uses pkgsrc package infrastructure, hence the the need
for extra flags.
Cmake pkg_search_module macro sets according <XPREFIX>_LDFLAGS var,
thus the correct way should be to append it to conky_includes and
conky_libs for each extra package needed.
As all pkgsrc packages always install in /usr/pkg, the simplest thing
is to set specific cflags and ldflags at the very beginning.
Conky is btw wip (work in progress) in pkgsrc system, mostly with
NetBSD patches. This is intended as radical workaround (DragonFlyBSD
specific for now) instead of submitting specific patches to pksrc
maintainers.
* process* management left to top.cc
* compile with -Wall -Werror (lots of wasted time for stupid errors)
* unify find_process() and new_process(), as used always together
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
* don't use kvm_* calls, just sysctl (so no suid perm necessary)
* sysctls calls in general aren't thread safe, collapse callbacks
using same sysctls (specifically total/running procs and proc list
ones).
Some sysctls need two calls (first to get size of obj returned,
second to get object self); if different threads use this schema
on same sysctl, weird values are returned (first/second calls
sequence should be serialized).
In general it makes not much sense too having more threads that use
the same sysctl; just get info once and populate all data.
* add DragonFly specific extended uname string ($version in conky.conf)
with git version and signature
Todo:
- top process list logic is old style, use top.cc funcs.
- find a solution for cpu freq
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
also change a magic constant in net_stat.h to reflect the fact that it depends on
MAX_NET_INTERFACES. For more info, see sf.net #2872682 and gentoo bug #384505
ps: this should really be solved in a more need way, without the need for static arrays
apparently, this was actually a feature as someone made it deliberately act that way. However, I
agree with the bug reporter that it is strange so I remove it.
Currently the variables related to xmms2 in conky do not update if the currently playing track
has any of its information updated (ie: the title changes). This results in incorrect behaviour
for streams where the same track is continually played but the title and artist change as new
songs are played. The attached patch corrects this issue by changing conky to respond to a
callback that fires when xmms2 media library entries are updated. After the callback fires, the
patch checks to see if the media library entry that changed corresponds to the currently playing
song and if it does updates the conky xmms2 related variables accordingly.
A different version of the patch was previously submitted and accepted into conky. Unfortunately,
this patch contained a bug that caused conky xmms2 variables to be updated when any media library
information was updated. However, the previous patch was reverted as a result of a commit the
made conky compatible with a new version of the xmms2 client api.
Patch submitted by Tamim Khan.
Signed-off-by: Pavel Labath <pavelo@centrum.sk>
this sort of fixes sf.net #3306538. The person there correctly tested for the existance of the
file with $if_existing, but the problem is we run the callbacks regardless of the conditional
tests.
Noone knows what it was supposed to do and removing it seems to fix sf.net #3411610 (and probably
a few others). If it turns out it was doing something useful, we will try to reintroduce it
without breaking other things.
