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.
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.
With some recent commits we are matching a good number of custom
characters. Instead of waiting for another one that breaks it, just
match all punctuation characters. The regexp is pretty big and some
simplification is also welcomed.
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.
There were not many changes recently, but much more people are taking
the tarball instead of the development code so they will benefit from
the recent fixes and extended documentation.
Adrian C. (anrxc)