Widget argument can now be a string (full path to the mbox) or a
table. In case of a table 1st field is full path to the mbox and 2nd
is maximum text lenght after which it will be truncated. If there is a
third field scrolling will be used - if so, 3rd field should be the
widget name.
Widget takes an optional argument that controls truncate and
scrolling. In case of a number truncate is used, it represents the
maximum lenght of widget text. In case of a table scrolling is used,
1st field is maximum lenght, and 2nd is widget name. An example:
{24, "mpdwidget"}
Thanks to Felix for bringing this to my attention. Obviously there was
already a safety net for feeding progressbars and graphs... and while
this makes for a good coding practice it's not a big deal. We have
widgets of type textbox for one, and a lot of string concatenation
happens. Strings are formatted, markup is applied...
This simplifies the code, in addition string.format is now used to
ensure all values have one decimal point at all time. We'll see how
recent changes and this one will affect people that use network graphs.
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.
If we return "N/A" like we usually do then format string "$1$2" would
look like "N/AN/A". If "/" is returned a progressbar could be
broken. Now returns are: symbol for state "unknown", 0 for battery
charge, N/A for remaining time.
If we return "N/A" like we usually do then format string "$1$2" would
look like "N/AN/A". If "/" is returned a progressbar could be
broken. Now returns are: symbol for state "unknown", 0 for battery
charge, N/A for remaining time.
Previous commit had redudant string > number conversions, and only
covered one scenario - when battery is charged. bioe007 suggested to
use math.min. Now lets explain why this is needed. Some (lousy)
batteries report "remaining capacity" higher than "last full capacity"
when AC is connected. That leads to battery charges like "160%".
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.
Adrian C. (anrxc)