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>
Draws a color-gradient beginning from fg and
if either fg_middle or fg_end is set, through them.
example config:
graph gr_cpu
{
data { scale = false max = 100 style = bottom
fg = "#cc6666" fg_half = "#cc6666" fg_full = "#998888"}
...
...
}
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>
There are the new styles:
bottom (fill the graph to the bottom of widget-square)
top (fill the graph to the top of the widget-square
line (just print a line representing the values)
E.g when there are multiple 'bottom'-style graphs, it will print the larger
part on top of the smaller. When two values are the same, it will (actually)
just print it with one color (something to improve maybe).
bottom-style overdraws top-style, and line-style overdraws top and bottom style
(= gets drawn at the end)
An example configuration:
graph gr_cpu
{
data { scale = false max = 100 fg = "#669966" style = bottom} # total
data { scale = false max = 100 fg = "#cc9966" style = bottom} # user
data { scale = false max = 100 fg = "#ffffff" style = bottom} # nice-processes
width = 50
height = "0.80"
bg = "#000000"
bordercolor = "#669966"
}
With the 'line' style, there is a bug (draws sometimes over the rectangle).
I checked the values and didn't find any value what actually should do that.
So I have no idea why that is... needs a recheck, because it's not really nice..
Happens especially when scale=true and after a rescaling takes place.
Signed-off-by: Julien Danjou <julien@danjou.info>
the graph_tell() does not modify directly the line-lenght to draw, rather
then calculating the value in percent and in the graph_draw, calculating
the line length ouf of that the percent.
(while trying to fix something little, a whole new scale thing resulted;
also I didn't really understand the old system, my fault that is)
I tend to prefer to not see a square on the taglist for tags which only
have skipped windows. E.g., if I run 'stalonetray --sticky
-w/--skip-taskbar', in which case it appears on all tags but not on the
tasklist, showing all of the tags as occupied seems somewhat awkward.
usage is simple:
,----
| echo "<screen> widget_tell <mytextbox> #[fg_color] #[bg_color] <text>" | awesome-client
| e.g.
| echo "0 widget_tell t normal behaviour" | awesome-client
| echo "0 widget_tell t #ff0000 red text on default background" | awesome-client
| echo "0 widget_tell t #ffffff #ff0000 white text on red background" | awesome-client
| ...
`----
the fg and bg colors are optional. if not given, the last state is
used.
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.