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.
This commit is contained in:
Adrian C. (anrxc)
parent
0dd5b72f01
commit
178a7eb88e
150
README
150
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
|
||||
--------------
|
||||
|
|
|
|||
Loading…
Reference in New Issue