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)