some issue is still there (anyway). When there are e.g. 5 horizontal bars
the width of that progressbar (multiply of 5 or similar) may won't be the
same like a graph.
So some tweaking on the graphs' height is necessary then.
data section values:
echo '0 widget_tell progess data title new_value' ...
data properties: fg, bg, fg_center, fg_end, bordercolor works like this:
echo '0 widget_tell progess fg_end title new_color' ...
universal settings to tune are gap, width, height, padding:
echo '0 widget_tell progess padding value' ...
actually the _tell function won't handle the new argument.
Coming patches will handle them.
it will need now something like this:
echo '0 widget_tell widget property value'
where property can be anything used in the awesomerc file,
that means what will be supported. Like: fg, fg_end, width, font...
(actually it ignores the property value and changes what have been changed in
the past as well.)
A hint from maxauthority. The names would be unified now in the progressbar
and the graph widget. And (hopefully) it's easier to guess what they mean now.
Signed-off-by: Julien Danjou <julien@danjou.info>
Adds an optional additional foreground color option to a bar: fg_full = <color>
A value of 0 represents the fg-color, and a value of 100 (a full graph) the
fg_full-color.
Example:
progressbar xy
{
bar { fg = "#111155" fg_full = "#3333cc" bg = "#000000" bordercolor = "#4444cc"}
....
}
Signed-off-by: Julien Danjou <julien@danjou.info>
example config:
graph gr_cpu {
width = 80
height = "0.8"
fg = "#336633"
bg = "#000000"
bordercolor = "#669966"
padding_left = 0
mouse = {...}
x = ...
y = ...
}
Looks like here: http://www.calmar.ws/tmp/112-Sun-screen.png
I renamed lpadding to padding_left, and bcolor to bordercolor
also on the progressbar widget.
The awesomerc page would still be to write, when this patch will get accepted.
Hints are always welcomed.
marco candrian
Julien Danjou
Nikos Ntarmos
