Instead of focusing the root window, we now create a "focus window" inside of
our frame window. This window is placed so that it is not visible, but we can
grab key bindings on it to simulate the window having the input focus.
Fixes: https://github.com/awesomeWM/awesome/issues/699
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes these methods invoke the method on a widget in a protected
context. Thanks to this, e.g. the wibox and other widgets are protected from
errors in a child widget.
Additionally, fit_widget() now assumes 0 if a widget's :fit() method didn't
provide a number.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This library is a wrapper around pcall() / xpcall() that prints an error message
via gears.debug.print_error() in case of errors.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a test that checks that :setup{ false } filters out the false, just
like it already filters out nil values. Then, this also adds a test that checks
that properties (:setup{ foo = false }) are not filtered out, because the first
version of me check did that accidentally.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Right now this just always returns the first screens, but this can easily be
implemented properly later.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I just spent too much time tracking down a bug that happened while drawing a
widget. This is the reason why we should apply sanity checks while widgets are
constructed, so that we get a useful backtrace.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the code use the existing functions for setting widgets. That way,
all the sanity checks that the existing functions have are applied for this code
as well.
I just spent half an hour tracking down a bug where a boolean ended up as a
"widget" in a fixed layout. The symptom was that while drawing the widget, an
error happened. Via this change, the error would instead be flagged while
constructing the widget.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Even when a screen is just an integer, the code becomes a bit more
self-documenting. Even better, if we start to handle screen objects to Lua
instead of screen indicies, there will only be one place that needs to be
changed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Because all our Lua code can now work with screen objects, most of the uses of
s.index that the previous patches added for reaching this goal can be removed
again.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes the code in awful.client work with screen objects where
possible (which is not possible in awful.client.movetoscreen() because it uses
screen_idx + 1).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commits makes a random selection of modules in awful support screen objects
and accept them as parameters everywhere where a screen index is accepted.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit documents that a textbox already accepts a screen object where a
screen index is expected. Also, this changes the widget API in that a widget's
context.screen is now a screen object instead of a screen index.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we manage the transient before the main window, the client object's
.transient_for property would stay nil. This happens because the property points
to a window which we don't know (yet) and thus is ignored.
Fix this by remembering the value of WM_TRANSIENT_FOR and checking in
client_manage() if the new client is the "missing window we did not find
before".
Fixes: https://github.com/awesomeWM/awesome/issues/181
Signed-off-by: Uli Schlachter <psychon@znc.in>
This creates a new helper function for setting the transient_for property of a
client. This is a preparation for a following commit. No behaviour changes
intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes awful.ewmh re-apply the maximized geometry to any maximized
clients when the workarea of a screen changes. This happens e.g. when a wibox
that is docked to the edge of the screen is hidden.
Fixes: https://github.com/awesomeWM/awesome/issues/705
Signed-off-by: Uli Schlachter <psychon@znc.in>
This avoids having to mock half the C API just because all of awful is loaded
needlessly in this unit test and is generally a good idea.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The argument to luaL_checkstack() is the amount of new stack to make available,
not the new size of the stack. Thus, remove the addition of lua_gettop(L) here.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In various conditions, luaA_loadrc() left luaA_dofunction_on_error and an error
message on the Lua stack. Also, it used LUA_MULTRET without looking at the
return values. Fix all of this and reorder the code a bit to make it easier to
follow.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The Lua stack is a finite resource and everything that pushes something there
should also clean up. This is not a problem for functions that are called by
Lua, because their "stack frame" is freed when they return. However, in global
context, Lua does not and cannot automatically clean up for us. Thus, it makes
sense to print a warning in this case.
(Additionally, this cleans up the stack if something is left)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds a new "luacheck" target to the Makefiles. This target is
automatically included in "make check" when luacheck is found in $PATH.
Additionally, this includes luacheck in Travis so that the build fails when
luacheck complains about something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
To quote from ICCCM (§4.1.2): "The window manager will not change properties
written by the client."
We tried to do this anyway to update WM_HINTS so that the current urgency state
is reflected. Apparently, Chrome does a similar read-modify-set cycle and the
resulting race condition meant that the "accepts input" hint on Chromium's
window was permanently disabled.
This helps with https://github.com/awesomeWM/awesome/issues/670, but I still
think that Chrome shouldn't try to implement "please don't focus me when I do
the following" by temporarily claiming "please don't ever focus me".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Step 1 starts a client and uses awful.rules to move it to a not-selected tag.
Because this rule still has focus=true, this calls awful.ewmh.activate() via the
request::activate signal. This function makes the client urgent because it is on
a not-selected tag.
Step 3 does the same thing, but also uses switchtotag=true. Now
awful.ewmh.activate() doesn't make the client urgent because it successfully
focused this client. However, the test was wrongly assuming that the client
became urgent (copy&paste error? I don't know).
The fix is of course not to require the client to become urgent.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit b2aaefd095, we correctly handle window gravities when
the border width of a client changes. Since most windows out there have a
NorthWest gravity, this means that most windows do not have this problem.
However, e.g. mplayer uses gravity "Static" and this causes this issue (any
gravity other than NorthWest will do).
This affects the fullscreen handling in awful.ewmh. The code has to set the
border width before it changes a client's geometry so that the move when the
border width changes doesn't matter.
No new integration test for this since I didn't find anything usable with a
non-NorthWest gravity. A test would be easy to write, just test if `c.fullscreen
= true ; c.fullscreen = false` restores the previous window geometry.
Fixes: https://github.com/awesomeWM/awesome/issues/697
Signed-off-by: Uli Schlachter <psychon@znc.in>
Lua 5.3's build system provides the LUA_COMPAT_5_2 and LUA_COMPAT_5_1 defines to
enable some compatibility with these older Lua versions. LUA_COMPAT_5_2 is
defined by default while LUA_COMPAT_5_1 is not.
This commit also disables LUA_COMPAT_5_2 on the Lua version that we build on
Travis so that the build will hopefully break if some feature is used that was
removed.
Signed-off-by: Uli Schlachter <psychon@znc.in>