A stack index without the corresponding lua_State pointer is useless, because it
could reference another coroutine than the main thread and thus just assuming
globalconf.L is wrong. Fix this by also passing around the corresponding
lua_State pointer.
This improves the result for the following test:
coroutine.resume(coroutine.create(function()
drawin({}).visible = true
end))
Signed-off-by: Uli Schlachter <psychon@znc.in>
I never saw a single program that set a border on its own windows. However,
awesome commonly sets borders on its clients and the position of a client is the
part outside of the border. So when processing a position request from a client,
we also have to include this border and fix things up correspondingly.
However, the same isn't needed for the client size, because the size does not
include the borders, but just the titlebar plus the "real" client content.
Thanks to Daniel Hahler for providing a simple test case based on urxvt for
debugging this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move the "index" setting burden to individual functions
instead of gettags().
* Add some properties earlier so the signal hooks will be called
with valid data.
The previous code assumed that pairs() iterates over the table in a specific
order which is not a safe assumption.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch allows 2 things to be done:
* Write unit test to validate layouts using fake clients and tags
* Query the current layout geometry from another tag
The advantages of the former are clear and simple. Those of the later include:
* Creating a screenshot of another layout
* Display the layout wireframe in the tag list (like KDE2-3, Gnome2)
* Having and 'ALT-tab' like visual popup for tags
This fixes the following code:
local d = drawin({})
d.visible = true
The drawin now has a cairo surface assigned
d.visible = false
d.width = 1234
d.visible = true
The width change while the drawin was not visible would not get propagated to
the drawable because of the code that this patch removes. The expectation was
that drawin_map() would update the drawable later.
However, because the drawin was already visible, its drawable also already has
a surface assigned. Thus, drawin_map() wouldn't update the drawable either.
Fix this by just removing this optimizations.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in drawin_moveresize() tries to be clever and only updates the drawing
state of the drawable when it is resized, not when it is moved around. This used
to be necessary because once upon a time, drawin_update_drawing() threw away all
of the drawing state and thus forcing a repaint. These days it just calls
drawable_set_geometry() as well and that function special-cases moves.
So this old code in drawin_moveresize() is no longer necessary and actually
caused problems.
These problems occurred because drawin_update_drawing() is being clever and
doesn't do anything for .visible = false drawins, because their drawing state
will be updated once they become visible. However, not skipping
drawable_set_geometry() means that this broke, because drawin_map() thought that
the drawing state was up to date while in reality it wasn't.
References: http://article.gmane.org/gmane.comp.window-managers.awesome/10852
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old code transformed the top-left and bottom-right corner of the rectangle
to device space and calculated a rectangle based on these two points. However,
if you rotate a rectangle by 45°, these two points will be directly above each
other and thus the old code would calculate a width of 0.
Fix this by transforming all four corners of the rectangle into device space and
calculating a rectangle based on this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This uses busted (http://olivinelabs.com/busted/) to implement unit testing.
This is wired up to "make check" and/or "make test".
This commit also adds tests for the more complicated parts of the gears and
wibox.layout libraries.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's just save the systray atom and keep it around. Why should we redo this
every time this atom is needed?
Signed-off-by: Uli Schlachter <psychon@znc.in>
We were looking for programs called cat, ln, grep and lua, but didn't ever use
the result of any of these searches. So let's just not search at all.
Signed-off-by: Uli Schlachter <psychon@znc.in>