Miroirs/awesome
1
0
Fork 0
mirror of https://github.com/awesomeWM/awesome synced 2024-11-17 07:47:41 +01:00
Code Issues Projects Releases Packages Wiki Activity Actions
1766 commits 10 branches 90 tags 37 MiB
Commit graph

204 commits

Author SHA1 Message Date
marco candrian
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
marco candrian
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
marco candrian
4e15b4fab4 [widgets/progressbar] calculate/return 'real' width (instead of d->width) when ticks are used 2008-04-12 04:49:15 +00:00
Julien Danjou
7124b8887c [tasklist] Fix focused client handling 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-04-07 20:34:42 +02:00
marco candrian
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
Julien Danjou
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
Julien Danjou
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
Julien Danjou
c43054bc4d [progressbar] check_settings should be static 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-04-02 08:46:32 +02:00
marco candrian
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
marco candrian
30de23d8c7 [widgets/progressbar] fix x-offset value (pb_x actually) 2008-04-02 06:26:17 +02:00
Julien Danjou
c4eaec5b82 [emptybox] Add alignment option 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-04-01 08:20:59 +02:00
Julien Danjou
3fbf7bd7d1 [emptybox] Remove align 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-31 15:58:33 +02:00
Julien Danjou
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
Julien Danjou
2fd0b3c008 [widgets] New emptybox widget 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-31 10:15:38 +02:00
Julien Danjou
c4cc8c5e04 [widgets] Remove paddings 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-31 10:04:03 +02:00
marco candrian
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
Julien Danjou
3ea69238ae [widgets/progressbar] Initialize unit value to 0 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-26 10:59:06 +01:00
marco candrian
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
marco candrian
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
Julien Danjou
1d468c5583 Lot of cosmetic changes: proto change, etc. 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-23 15:52:22 +01:00
Julien Danjou
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
Julien Danjou
8d0e5b29a6 Cosmetic formating changes 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-23 15:52:22 +01:00
Julien Danjou
a3f9eb7af9 Revert "Add preliminary support for XPM format" 
This reverts commit 5f8b538a5e4eeea159b26c3d0b943cac745ffdce.
 2008-03-23 15:52:22 +01:00
Julien Danjou
df2555d9fe Add preliminary support for XPM format 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-23 15:52:22 +01:00
Julien Danjou
2a47aa7f0b Add cfg_getalignment() functions 
Signed-off-by: Julien Danjou <julien@danjou.info>
 2008-03-23 15:52:21 +01:00
Julien Danjou
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
Julien Danjou
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
Julien Danjou
fe8bd0bb5b Implement a CFG_POSITION type and use it 2008-03-23 15:52:21 +01:00
marco candrian
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
Julien Danjou
a47e3d26d5 Add support for urgent style in tasklist 2008-03-23 15:52:21 +01:00
Arnaud Fontaine
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
Julien Danjou
403d7e89f9 Compute style when we need to. 2008-03-23 15:52:20 +01:00
marco candrian
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
Julien Danjou
ece6ffb8fe Fix background color for icons in tasklist 2008-03-23 15:52:19 +01:00
Julien Danjou
c6eec955c8 Rename Area to area_t 2008-03-23 15:52:18 +01:00
Julien Danjou
a2082ffbae Factorize some code with taglist_style_get() 2008-03-23 15:52:18 +01:00
Julien Danjou
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
Julien Danjou
9dfd488dda Change colors handling 2008-03-23 15:52:18 +01:00
marco candrian
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
marco candrian
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
marco candrian
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
marco candrian
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
Julien Danjou
0a980095b3 Rework colors stuff, add a common colors_ctx_t containing colors and shadow options 2008-03-23 15:52:17 +01:00
Julien Danjou
5f26ab448c Free the previously opened font if changing it via widget_tell in textbox 2008-03-23 15:52:17 +01:00
Julien Danjou
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
marco candrian
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
marco candrian
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
397aa33163 widget error infrastructure additions 2008-03-23 15:52:16 +01:00
Julien Danjou
0e69534a65 Add a common error infratructure for widget_tell 
Signed-off-by: Marco Candrian <mac@calmar.ws>
 2008-03-23 15:52:16 +01:00
marco candrian
3efadded39 graph widget handles property arguments now 
data section values:

echo '0 widget_tell progess data title new_value' ...

universal settings  are width, height, padding_left, bg, bordercolor like:

echo '0 widget_tell progess height value' ...
 2008-03-23 15:52:16 +01:00