E.g. to get single line (or rectangle with width = 1 etc), the path should go
through the center of the pixels (.5), when that path gets stroked finally, it
filles the pixels fully.
Signed-off-by: Julien Danjou <julien@danjou.info>
Fixes FS#162 now also on my PC in any way (it filled the pixels on the right
when a gradient was given, else the one on the left of x.
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)
I added an option to the configure script to link against gdk instead
of imlib2. Most people already have gdk installed so that way they can
use awesome without installing imlib2, and gdk's pixbuf was explicitly
designed to replace imlib2.
Also, a nice side effect is that GDK works directly with cairo
surfaces, so the process of loading images should be faster, although
since awesome does very little image loading it probably wont have a
noticable impact on performance, but it certainly won't hurt.
Signed-off-by: Julien Danjou <julien@danjou.info>
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>
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
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>
Without a new (sub)path, it joined the new circle to the old reference point,
what happend to be at the end of the title-text - therefore the line to it with
cairo_stroke()
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>
marco candrian
Julien Danjou
Alex Cornejo
Martin Stubenschrott
Arnaud Fontaine