A lot of people expect widgets like this one to auto-magically work,
and somehow don't understand that *they* need to make sure there is a
source of information. Is ACPI module loaded? Is battery info exposed
in the same place that widget expects by default? You need to answer
those questions before loading the widget and sending me "bug"
reports.
Vicious modules can be resued for other objects, like awful tooltips
or naughty notifications. We call a module directly and manipulate the
result until we have some nice output to display. For example, a wifi
widget could be a progressbar with the signal level, but on mouse
enter a tooltip is created with ssid/mode/channel information.
If a channel is muted we return 0. Something like "Muted" would be
nice, but lets not break progressbars. If it doesn't concern you, then
return what ever you want...
We still stick to ACPI thermal zones because they are most commonly
exposed (with proper ACPI modules loaded). But if you can find another
source of temperature exposed trough /sys use it. Current code should
match a lot of sources, but in some cases you will want to modify it a
bit, add a dot, or limit to two numbers (except when the value is
100+, you don't want to miss the fact your CPU is melting).
It also won't break anymore when voltage support is missing since it
happens so often. But there are no handlers for the frequency or
governors - if you don't have those what the hell are you doing with
this widget anyway?
Widget now uses the Gmail unread tag to get a list of all unread
messages, not only the Inbox. The auth argument was removed, and login
information should now be placed directly in the widget (and file made
read-only by user) until a safer storage is introduced.
By default only local file systems are included now. In case a mounted
NFS share dissapears from the network the widget would be left hanging
there and has the potential to block everything else (including
awesome it self). File system widget now takes an optional argument
which, if true, will include remote file systems.
Adrian C. (anrxc)