66d24bb191
[progressbar] fix vertical-reversed bar + cosmetic
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-17 09:50:00 +02:00
3f1c8a9479
[progressbar] about cosmetic
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-17 09:49:49 +02:00
96fe2ec6fd
[widgets/graph] when grow=right, fg_end in on the left of the rectangle (FS#163)
2008-04-14 04:23:57 +02:00
bc7d9211ba
[widgets/graph] offset fixed now.
...
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)
2008-04-14 04:21:52 +02:00
62ac090368
[common/draw] curious (cairo?) bug, sometimes draws the line 1 pixel to much on the right
...
happens only when creating a gradient, and not always, and
adding + 1 (creating a slightly diagonal gradient), seems to help a little bit).
2008-04-12 06:56:14 +00:00
4e15b4fab4
[widgets/progressbar] calculate/return 'real' width (instead of d->width) when ticks are used
2008-04-12 04:49:15 +00:00
7124b8887c
[tasklist] Fix focused client handling
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-07 20:34:42 +02:00
4a7ebc9c5c
[widgets/progressbar] fix FS#145 - empty progressbar draws one pixel too far
...
+ check_settings should be below the check for data_items (count).
+ some fix on check_settings
2008-04-02 15:51:30 +02:00
c582f4397b
[widgets] Check for no value in uicb_widget_tell and only update sbar on no error
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-02 15:31:19 +02:00
a79cb3f927
[config] Add a bunch of new checks in configuration file
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-02 09:17:25 +02:00
c43054bc4d
[progressbar] check_settings should be static
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-02 08:46:32 +02:00
ed231336fb
[widgets/progressbar] try to prevent the bug FS#141
...
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.
2008-04-02 06:26:17 +02:00
30de23d8c7
[widgets/progressbar] fix x-offset value (pb_x actually)
2008-04-02 06:26:17 +02:00
c4eaec5b82
[emptybox] Add alignment option
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-04-01 08:20:59 +02:00
3fbf7bd7d1
[emptybox] Remove align
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-31 15:58:33 +02:00
6c6d86eef1
[widgets/graph] Fix regression in padding removal (FS#139)
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-31 14:31:58 +02:00
2fd0b3c008
[widgets] New emptybox widget
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-31 10:15:38 +02:00
c4cc8c5e04
[widgets] Remove paddings
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-31 10:04:03 +02:00
0e1dbe40d2
[widgets/progressbar.c] x_offset+1 and bg color fix
...
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.
2008-03-28 09:53:50 +01:00
3ea69238ae
[widgets/progressbar] Initialize unit value to 0
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-26 10:59:06 +01:00
89f4e22255
[widgets] new progressbar options
...
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>
2008-03-26 10:02:37 +01:00
b92a292e43
additional line width argument to draw_rectangle[_gradient] in draw.c
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:22 +01:00
1d468c5583
Lot of cosmetic changes: proto change, etc.
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:22 +01:00
0a6c6e017b
Store physical screen id in statusbar and client, change get_phys_s() to screen_virttophys()
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:22 +01:00
8d0e5b29a6
Cosmetic formating changes
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:22 +01:00
a3f9eb7af9
Revert "Add preliminary support for XPM format"
...
This reverts commit 5f8b538a5e4eeea159b26c3d0b943cac745ffdce.
2008-03-23 15:52:22 +01:00
df2555d9fe
Add preliminary support for XPM format
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:22 +01:00
2a47aa7f0b
Add cfg_getalignment() functions
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:21 +01:00
7b1ce042de
Add cfg_getposition() and cie to ease libconfuse compatibility
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:21 +01:00
19656fc36d
Add a CFG_ALIGNMENT type and use it
...
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:21 +01:00
fe8bd0bb5b
Implement a CFG_POSITION type and use it
2008-03-23 15:52:21 +01:00
214a5c4bfa
new graph-widget option: grow = <{right, left}>
...
Signed-off-by: Marco Candrian <mac@calmar.ws>
Signed-off-by: Julien Danjou <julien@danjou.info>
2008-03-23 15:52:21 +01:00
a47e3d26d5
Add support for urgent style in tasklist
2008-03-23 15:52:21 +01:00
542a944361
Use Pango for fonts instead of Xft (which hasn't been ported yet to
...
XCB) to measure text.
2008-03-23 15:52:21 +01:00
403d7e89f9
Compute style when we need to.
2008-03-23 15:52:20 +01:00
29673467f9
change graph's style to draw_style
...
to prevent confusion with the other style {} sections,
and it might also better describes what is it used for..
2008-03-23 15:52:20 +01:00
ece6ffb8fe
Fix background color for icons in tasklist
2008-03-23 15:52:19 +01:00
c6eec955c8
Rename Area to area_t
2008-03-23 15:52:18 +01:00
a2082ffbae
Factorize some code with taglist_style_get()
2008-03-23 15:52:18 +01:00
fa47024714
Change colors infrastructure to style: rename colors_ctx_t to style_t and add font in it
2008-03-23 15:52:18 +01:00
9dfd488dda
Change colors handling
2008-03-23 15:52:18 +01:00
2e6dccc5ac
make sure command is some text != ""
...
else call with command arg = NULL
No need to check for a_strlen(command) then on _tell anymore if command != NULL
2008-03-23 15:52:18 +01:00
d1e216936c
try to calculated the height etc in the same way on progressbar and graph
...
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.
2008-03-23 15:52:18 +01:00
b1b2b48a4c
graph: different widget index's (FIXME) handled now
...
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.
2008-03-23 15:52:18 +01:00
2e935ae1f6
vertical_gradient option for the graph widget
...
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
2008-03-23 15:52:17 +01:00
0a980095b3
Rework colors stuff, add a common colors_ctx_t containing colors and shadow options
2008-03-23 15:52:17 +01:00
5f26ab448c
Free the previously opened font if changing it via widget_tell in textbox
2008-03-23 15:52:17 +01:00
f3652aaca6
Add a pointer to SLIST struct to store previous element
...
This will make back cycling faster
2008-03-23 15:52:17 +01:00
04ff373a63
New progressbar option: vertical=<boolean>
...
if 'true', draws the whole progressbar-block vertically
instead of horizontally.
2008-03-23 15:52:16 +01:00
6216d25bc6
new progressbar option for reversing the drawing
...
inside a data section, with reverse=<boolean> it's possible to reverse the
drawing i.e instead of left to right, from right to left. etc.
2008-03-23 15:52:16 +01:00
marco candrian
Julien Danjou
Arnaud Fontaine