Widget type now takes the thermal zone as an argument, or a table with
1st field as thermal zone and 2nd field as data source. Available data
sources are: "proc" (procfs ACPI), "sys" (sysfs like before) and
"core" (sysfs coretemp). When only the thermal zone is provided widget
defaults to "sys".
This widget type now takes the distribution name as an argument; Arch,
Arch S, Debian and Fedora examples are now in the package manager
table. Feedback from yum users is needed.
This changes keys that are returned, previously only total I/O was
available in: {raw}, {kb} and {mb}. Keys returned now are (s=raw):
{total_s}, {total_kb}, {total_mb}, {read_s}, {read_kb}, {read_mb},
{write_s},{write_kb} and {write_mb}.
Previous version could return 1 on one update and 900 on the next (1st
being GB, 2nd MB) a user appending "GB" to the value suddenly has a
900GB disk available. Returned keys are now: size_mb, size_gb,
used_mb, used_gb, avail_mb, avail_gb, and percentage is now: used_p.
Default path is set to /sys/class/thermal but at least it's easier to
switch to /sys/class/hwmon (i.e. coretemp) now without much code
modification. Note; zone IDs are probably different than those in
/proc/acpi/thermal_zone
Initial widget code was sent by Benedikt Sauer. After some cleanup it
is ready to go into master. It uses data exposed trough /sys and it is
used in the exact same way as the bat widget (and /proc). This widget
will replace batat and acpitool, it will be moved to contrib and
retired.
Vicious will now divide values by 100 to match the default graph
max_value of 1. Graphs support changing this value, but progressbars
don't. We shouldn't use 100 for one and 1 for the other.
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.
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.
Widget returns the count of new and subject of last e-mail in a Gmail
inbox. Use ${count} and ${subject} in the format string to retrieve
the values. Widget takes a table with login information as an
argument.
I don't like how gmail widgets handle sensitive data but I gave in
seeing how popular they are. Better storing and handling of login
information would be in order but this isn't Python and I'm out of
ideas. For now use it on your own responsability, I would suggest to
set login info directly in the widget and file as read-only by user.
Now that vicious git repo is served trough a public web interface
there is no need for a full changelog. I considered removing it
completely, but it will have to wait - before the web interface
tarballed tags were requested much more than the repo was
cloned. Maybe that will change now, in which case the file should be
removed and stop wasting space.
Vicious tags from 1.0.12 will not be compatibile with awesome versions
prior to 3.4, tag 1.0.11 was the last one. Vicious was ported to the
new timer signals infrastructure and there is no backward
compatibility with hooks. In 1.0.12 even those C widgets that are
deprecated in awesome 3.4 (to be removed in 3.5) will not be
supported. Use awful.widget.progressbar and awful.widget.graph.
The cpufreq widget supplements the cpu widget. It returns the current
CPU scaling frequency (in MHz and GHz), voltage (in mV and V) and
governor information for a requested CPU. If supported by the
processor and correct kernel modules are loaded.
The, mboxc, widget supplements the mbox widget. The mbox widget
returns the subject of the last e-mail in a mbox, while the mboxc
widget returns the count of total, old and new messages. Dealing with
potentially *HUGE* files is not easy, I tried to find some middle
ground for now, comments in the file discuss it in detail. Having the
LuaFileSystem lib would be nice, so we could do caching and avoid 90%
of the reads, but I didn't rely on external libraries to this point so
I'm not going to start now.
Adrian C. (anrxc)
Hiltjo Posthuma