This option is no longer valid in modelines, so it has been removed from
all modelines using the following shellscript:
#!/bin/ksh
git ls-tree -r HEAD | cut -f2 | while read f; do
egrep -e '^(//|--) vim: .*encoding=' $f >/dev/null || continue
sed -E -e '/^(\/\/|--) vim:/s/:encoding=utf-8//' $f > /tmp/foo
mv /tmp/foo $f
done
Signed-off-by: Gregor Best <gbe@ring0.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's just quote the bug report:
A regression was introduced in commit f5a5af4001
which causes wiboxes to position themselves incorrectly on Xinerama screens
besides the first one. In lib/awful/wibox.lua.in line 49, function
set_position(), the screen number used to use wibox.screen but now just defaults
to 1. Since the screen parameter is never actually passed to set_position(),
that means that wiboxes will always use screen 1's geometry when determining the
proper position. So, if a different screen is larger or smaller or isn't aligned
with the primary screen, the wibox will either be offscreen or not on the edge.
This should be fixed by explicitly passing the right screen argument to all
functions which need it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Setting width or height (horizontal or vertical) to an arbitrary value
causes the wibox not to be stretched. Instead the align() function is
called, which might not modify any wibox property in many situations,
or none when align parameter was not provided by the user. The major
side effect is that wibox struts were never updated and clients
covered the wibox (until a first signal handler caused struts to be
updated).
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
Changing the width or height of a (right or bottom positioned)wibox,
after it was initialized, to a value different than used when it was
created would leave the wibox in a wrong position. Position was off by
as many pixels as the difference between the old and the new
value. Now every wibox is repositioned to reflect this new setup.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
When both height and width arguments are provided to the function
new() there is a check to see if one of them was a screen percentage,
and is expected to be a string. If the user provided absolute pixels,
and argument is of type number awesome will crash. Now tostring is
used to sanitize the arguments during this check.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
awful.wibox.align() in 3.4.x gets the available screen area from
capi.screen[screen].geometry.
this can easily result in overlapping wiboxes since the work area
provided does not account for existing wiboxes.
In my configuration I use a vertical wibox positioned at the
right and it half-overlaps my top wibox because it is streched and
hard-coded to align at the middle.
Signed-off-by: Julien Danjou <julien@danjou.info>
Function wibox_update_strut would not take the border width into
account when calculating struts. When a wibox border was in use
clients would overlap the wibox. With a border of 1px we loose 1px of
the wibox, but as the wibox border increases it is "pushed" by the
border nearest the screen edge and clients steal more and more space.
Signed-off-by: Adrian C. (anrxc) <anrxc@sysphere.org>
Signed-off-by: Julien Danjou <julien@danjou.info>
This uses hexadecimal colors, because named colors require a round trip to the X
server and are thus slower. :(
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
If a wibox with non-north position was created and a wibox size was specified,
this function happily ignored it when it made the wibox fit.
Thanks to Garoth who found this bug.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
Remove an unused var and fix a reference to capi.awesome
Signed-off-by: Uli Schlachter <psychon@znc.in>
Signed-off-by: Julien Danjou <julien@danjou.info>
This patch fixes a bug and changes the position handling for wiboxes:
The bug was that awful.wibox.set_position() didn't update the cached
wibox position, i.e. the wibox was moved, but the position value in the
wiboxes table stayed the same
The change in position handling was that unknown positions (i.e.
"fnord") default to "floating"
Signed-off-by: Gregor Best <farhaven@googlemail.com>
Signed-off-by: Julien Danjou <julien@danjou.info>
Arvydas Sidorenko
Gregor Best
Uli Schlachter
dodo
Julien Danjou
Adrian C. (anrxc)
Pierre Mazière
Alex Alexander
Lukas Hrazky
Gregor Best
Gregor Best