README: added contrib and vicious-fbsd information

Contrib should be better known because of the extra widgets it
contains. While the vicious-fbsd branch by Richard Kolkovich was
already added to the vicious home page and needs more exposure.

1 files changed, 82 insertions, 68 deletions

diff --git a/README b/README
index 88eb4b3..df007ba 100644
--- a/README
+++ b/README
@@ -89,74 +89,6 @@ Force update of widgets:
       updated
 
 
-Power and Caching
------------------
-When a lot of widgets are in use they, and awesome, can generate a lot
-of wake-ups and also be very expensive for system resources. This is
-especially important when running on battery power. It was a big
-problem with awesome v2 and widgets that used shell scripts to gather
-data, and with widget libraries written in languages like Ruby.
-
-Lua is an extremely fast and efficient programming language, and
-Vicious takes advantage of that. But suspending Vicious widgets is one
-way to prevent them from draining your battery, despite that.
-
-Update intervals also play a big role, and you can save a lot of power
-with a smart approach. Don't use intervals like: 5, 10, 30, 60... to
-avoid harmonics. If you take the 60-second mark as an example, all of
-your widgets would be executed at that point. Instead think about
-using only prime numbers, in that case you will have only a few
-widgets executed at any given time interval. When choosing intervals
-also consider what a widget actually does. Some widget types read
-files that reside in memory, others call external utilities and some,
-like the mbox widget, read big files.
-
-Vicious can also cache values returned by widget types. Caching
-enables you to have multiple widgets using the same widget type. With
-caching its worker function gets executed only once - which is also
-great for saving power.
-
-  - Some widget types keep internal data and if you call one multiple
-    times without caching, the widget that executes it first would
-    modify stored values. This can lead to problems and give you
-    inconsistent data. Remember it for widget types like CPU and
-    Network usage, which compare the old set of data with the new one
-    to calculate current usage.
-
-  - Widget types that require a widget argument to be passed should be
-    handled carefully. If you are requesting information for different
-    devices then caching should not be used, because you could get
-    inconsistent data.
-
-
-Security
---------
-At the moment only one widget type (Gmail) requires auth. information
-in order to get to the data. In the future there could be more, and
-you should give some thought to the issue of protecting your data. The
-Gmail widget type by default stores login information in the ~/.netrc
-file, and you are advised to make sure that file is only readable by
-the owner. Other than that we can not force all users to conform to
-one standard, one way of keeping it secure, like in some keyring.
-
-First let's clear why we simply don't encrypt the login information
-and store it in ciphertext. Answer is simple, that is no more secure
-than having it stored in plaintext. By exposing the algorithm anyone
-can reverse the encryption steps. Some claim even that's better than
-plaintext but it's just security trough obscurity.
-
-Here are some ideas actually worth your time. Users that have KDE (or
-parts of it) installed could store their login information into the
-Kwallet service and request it via DBus from the widget type. It can
-be done with tools like "dbus-send" and "qdbus". The Gnome keyring
-should support the same, so those with parts of Gnome installed could
-use that keyring.
-
-Users of GnuPG (and its agent) could consider encrypting the netrc
-file with their GPG key. Trough the GPG Passphrase Agent they could
-then decrypt the file transparently while their session is active.
-
-
 Widget types
 ------------
 Widget types consist of worker functions that take the "format"
@@ -332,6 +264,88 @@ own. Write a quick worker function that does the work and plug it
 in. How data will be formatted, will it be red or blue, should be
 defined in rc.lua (or somewhere else, outside the actual module).
 
+Before writing a widget type you should check if there is already one
+in the [contrib] branch of Vicious. The [contrib] branch contains
+extra widgets you can use. Some are for less common hardware, and
+other were contributed by Vicious users. The [contrib] branch also
+holds widget types that were deprecated, rewritten or removed from the
+[master] branch.
+
+  http://git.sysphere.org/vicious/log/?h=contrib
+
+Richard Kolkovich, a FreeBSD user, published his vicious-fbsd
+branch. If you are also a BSD user you can find his work here:
+
+  http://git.sigil.org/vicious-fbsd/
+
+
+Power and Caching
+-----------------
+When a lot of widgets are in use they, and awesome, can generate a lot
+of wake-ups and also be very expensive for system resources. This is
+especially important when running on battery power. It was a big
+problem with awesome v2 and widgets that used shell scripts to gather
+data, and with widget libraries written in languages like Ruby.
+
+Lua is an extremely fast and efficient programming language, and
+Vicious takes advantage of that. But suspending Vicious widgets is one
+way to prevent them from draining your battery, despite that.
+
+Update intervals also play a big role, and you can save a lot of power
+with a smart approach. Don't use intervals like: 5, 10, 30, 60... to
+avoid harmonics. If you take the 60-second mark as an example, all of
+your widgets would be executed at that point. Instead think about
+using only prime numbers, in that case you will have only a few
+widgets executed at any given time interval. When choosing intervals
+also consider what a widget actually does. Some widget types read
+files that reside in memory, others call external utilities and some,
+like the mbox widget, read big files.
+
+Vicious can also cache values returned by widget types. Caching
+enables you to have multiple widgets using the same widget type. With
+caching its worker function gets executed only once - which is also
+great for saving power.
+
+  - Some widget types keep internal data and if you call one multiple
+    times without caching, the widget that executes it first would
+    modify stored values. This can lead to problems and give you
+    inconsistent data. Remember it for widget types like CPU and
+    Network usage, which compare the old set of data with the new one
+    to calculate current usage.
+
+  - Widget types that require a widget argument to be passed should be
+    handled carefully. If you are requesting information for different
+    devices then caching should not be used, because you could get
+    inconsistent data.
+
+
+Security
+--------
+At the moment only one widget type (Gmail) requires auth. information
+in order to get to the data. In the future there could be more, and
+you should give some thought to the issue of protecting your data. The
+Gmail widget type by default stores login information in the ~/.netrc
+file, and you are advised to make sure that file is only readable by
+the owner. Other than that we can not force all users to conform to
+one standard, one way of keeping it secure, like in some keyring.
+
+First let's clear why we simply don't encrypt the login information
+and store it in ciphertext. Answer is simple, that is no more secure
+than having it stored in plaintext. By exposing the algorithm anyone
+can reverse the encryption steps. Some claim even that's better than
+plaintext but it's just security trough obscurity.
+
+Here are some ideas actually worth your time. Users that have KDE (or
+parts of it) installed could store their login information into the
+Kwallet service and request it via DBus from the widget type. It can
+be done with tools like "dbus-send" and "qdbus". The Gnome keyring
+should support the same, so those with parts of Gnome installed could
+use that keyring.
+
+Users of GnuPG (and its agent) could consider encrypting the netrc
+file with their GPG key. Trough the GPG Passphrase Agent they could
+then decrypt the file transparently while their session is active.
+
 
 Usage examples
 --------------