Drawing the border after the graph-drawing, allows to draw down to the border itself
when 0 values occur.
Signed-off-by: Julien Danjou <julien@danjou.info>
In fact on my pc, when there is no fg_end or fg_center defined,
it draws it one pixel too much on the right.
On Gigamo's PC, that patch should work on any case.
It also 'should' work from what I guess!
For people having a problem, they could define fg_end to the same as fg.
Or when it's really serious (on not just here), that could be done inside
awesome.
(Finally somekind of little cairo bug, from my perspektive)
The real cause for it is unknown to me. I personally can't reproduce it.
Even when it won't fix, that patch makes still sense so:
no drawing of a rectangle what will get 'overdrawn' fully anyway.
the widget got drawn 1 pixel to much on the left.
adding one progressbar x offset (pb_x) seems to work nicely.
also. bg shall draw (according to the manpage), the gaps
between the 'ticks' + the padding between the border and the ticks
(... everthing inside the border only the ticks)
so, an additional rectangle draw line to achieve that basic bg color.
if a ticks_count is defined (!= 0), round the value to them ('ticks')
and draw finally some gaps.
Also an important issue: since the bar needs to be 'homogenous', they may won't
match a given height. Some value tweaking will be necessary then.
An alternative would be a not homogenous bar, what is worse I think.
The values, when there are 'ticks', get rounded up somebit. So they get turned on,
when half of them is reached - or so.
new options (see awesomerc.5.txt for a more detailed description):
border_width
border_padding
fg_off
ticks_count
ticks_gap
Signed-off-by: Julien Danjou <julien@danjou.info>
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.
widget_tell can feed data to some with another frequenzy.
When drawing a line, it has to be searched for a smaller value, what should
not get overdrawed. In order to find such a smaller value, the correct value
has to be compared to - and therefore the correct index.
if true, the color values (fg, fg_center, fg_end) create a color gradient
from 0 to full value, instead of new values to old values.
each data{} can have it's own setting
marco candrian
Julien Danjou
Arnaud Fontaine