I'm made some simple modifications of awesome-menu.c
to achieve the following:
1. Match the string entered by the user with the whole search string.
So far, it only matches from the start of the string. For menu entries
like 'gksu synaptic', the default behaviour is very inconvenient,
because obviously, I don't want to enter the 'gksu' part every time.
Another example: I have iceweasel, iceape and icedove installed.
Entering 'wea' is enough to find 'iceweasel' exclusively if the whole
string is searched. 'ice', on the other hand, won't do much good.
2. If there's just one single match, select that one automatically.
This saves hitting tab once in the cases when the choice is obvious
(because there is only one).
Signed-off-by: Julien Danjou <julien@danjou.info>
Antialiasing also has the advantage, that the path get's drawn now precisely -
there have been some issues without ... depending on the line-angle, some
pixels weren't filled on some y coordinates etc.
Signed-off-by: Julien Danjou <julien@danjou.info>
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>
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)
Before awesome 2.3 release, I've decided to look for typos in the
awesome* manpages, here is the result. I've also modified some options'
descriptions that I didn't find very clear, I hope I have not
added/missed too many mistakes as I'm not a native English speaker...
Signed-off-by: Julien Danjou <julien@danjou.info>
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>
Hannes
Julien Danjou
Nikos Ntarmos
marco candrian
Fabienne Ducroquet
Alex Cornejo
Martin Stubenschrott
Steffen Schulz