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
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>
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.
I hacked together support for custom netwm icons set in the rules
section of .awesomerc, and for iconboxes and netwm icons to be scaled
to fit into the statusbar. It could probably be done a bit more
cleanly than I've done it, though :)
Rob
protocol to speak to them. Given a textbox widget definition like this:
textbox mail {
default = 0
}
textbox time {}
We can update the boxes individually by going:
echo 0 tell_widget mail 10
echo 0 tell_widget time 12:01
Text boxes will dynamically resize to fit their contents. A textbox can be
cleared by going:
echo 0 tell_widget name
A text-box containing no text will take up 0 space in the bar, i.e. it will not
be visible at all
Textboxes now supersede statusbar_set_text, so this call has been removed.
The big change here is that we now keep our configuration structure in a global
variable called globalconf. This radically simplifies many interfaces, since
passing awesomeconf everywhere is no longer necessary. There are also more
subtle interface effects - now we can reliably identify a screen from just a
screen ID, rather than an awesomeconf, screenid tuple.
Overall, this patch makes most of the interfaces in awesome much nicer to use -
enjoy!
Yes, this is a huge patch, but since a lot of the refactoring was done
systematically using vim macros, splitting this up would have been very hard.
We now have the beginnings of a flexible widget structure for the statusbar.
For now, there is no behavioural change, and the interface is a bit crude, but
watch this space!
marco candrian
Julien Danjou
Arnaud Fontaine
Nikos Ntarmos
Rico Schiekel
Hans Ulrich Niedermann
Robert Millar
Aldo Cortesi
