The function window_set_border_width() causes its own gravity handling.
Thus, to make sure that this gravity handling does not interfere with
what the code in here does later, we just apply changes to the border
width first, and then do everything else.
Signed-off-by: Uli Schlachter <uli.schlachter@informatik.uni-oldenburg.de>
Before this commit, the code in here first handled clients changing its
x/y position and afterwards it handled resizes. This meant that the
special case of "client resizes without moving itself so we need to
apply gravity" had to have special checks on whether the client moved
itself or not.
Change the code so that resizes are handled first and moves later. This
naturally handles the problem: If the client resizes and moves itself,
the move done for the resize is later overwritten when the move is
handled.
No functional changes are intended.
Signed-off-by: Uli Schlachter <uli.schlachter@informatik.uni-oldenburg.de>
Some window gravities require a division by two. Up to now,
test-gravity.c expected this division to always be rounded up. This
commit changes the code to also allow rounding down.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, this function overwrote the value of its argument with the
result. After this change, the function merely changes the given
variable by the calculated argument.
Thus, the old behaviour is achieved by setting the variable to zero
before the call, which all callers already did. However, for most
callers this change means that a temporary variable can be removed and
instead xwindow_translate_for_gravity() will directly change the target
variable.
No change in behaviour intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are two ways in which the input focus can change: Lua can request
a change and the X11 server can inform us that the input focus changed
(because some application changed it).
In the first case, we still have to inform the X11 server about the
desired change, in the second case we must not to avoid races due to
X11's asynchronous nature.
However, there was a case where we screwed up: When a focus change is
still pending, meaning that Lua assigned the focus elsewhere, but we
have not yet sent this focus change to the X11 server, we could get an
event from the X11 server telling us that the focus changed. To make
sure that the pending focus change is not lost, we sent the focus change
out in this case (call to client_focus_refresh() in
event_handle_focusin()). After sending out this pending call, we updated
the internal state to record that whatever the X11 server just told us
had the focus. The intention was that our just sent-out focus change
will cause the X11 server to send a new event and our to-be-focused
client then has the focus.
However, if the pending focus change was for a client which only showed
up in this event loop iteration, the client was still banned. This means
that client_focus_refresh() would call client_unban() to be able to give
the focus to this client. However, since awesome (partly) allows to
"focus" currently banned clients, client_unban() recorded that there is
a pending focus change. This caused confusion later on.
In this specific bug, a main window opened a dialog, and when this
dialog was closed, a new dialog window was opened immediately. When the
first dialog was closed, Lua (the focus history) gave the input focus to
the main window. Now, a new dialog showed up and Lua focused it. Next,
we received the event from the X11 server telling us that the main
window was focused. Because there was still a pending focus change to
the new dialog window, event_handle_focusin() called
client_focus_refresh() to send out this focus change. This set
globalconf.focus.need_update to false and continued. However, because
the new dialog only just now appeared, it was still banned, meaning that
client_focus_refresh() had to call client_unban(). This set
globalconf.focus.need_update to true. Thus, when client_focus_refresh()
returned, globalconf.focus.need_update was incorrectly true. Next,
event_handle_focusin() recorded that the main window had the focus.
Thus, it now appeared as if there was a pending focus change for the
main window. Next, we got the event from the X11 server telling us that
the dialog is now focused, and because focus.need_update was set,
awesome now send out a focus change request for the main window.
Fix this race by unsetting globalconf.focus.need_update at the end of
client_focus_refresh() and not at the beginning, thus making sure that
client_unban() cannot set this flag again.
Fixes: https://github.com/awesomeWM/awesome/issues/2220
Signed-off-by: Uli Schlachter <psychon@znc.in>
The typo was introduced in commit a1941efc9.
Its effect should be minimal: :item_enter() itself does not care about
the 'mouse' option, but it forwards to :exec(). Here, an action is
invoked either if it was not caused by the mouse, or if it was caused by
the mouse and either auto_expand is enabled (which is the default), or
the item-to-be-executed is actually the active item.
In other words, it is quite non-trivial to come up with a case where
this typo made a difference. But of course that's no reason to leave the
typo in.
Fixes: https://github.com/awesomeWM/awesome/issues/2347
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a window has a WM_TRANSIENT_FOR property that is later unset,
awesome would still keep c.transient_for pointing to the previous
"parent client". This commit fixes that.
First, property_update_wm_transient_for() is fixed so that it unsets
c->transient_for_window if the WM_TRANSIENT_FOR property is deleted.
Additionally, this then calls client_find_transient_for() to update the
c->transient_for pointer.
Secondly (and a bit unrelated), this changes client_find_transient_for()
so that it always sets c->transient_for. Previously, if updating this
property would introduce a cycle in the transient_for relation, it would
just leave c->transient_for with its old value. After this change, it
gets explicitly set to NULL instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old keygrabber API wasn't doing what the users want from a
keygrabber module. With tons of boilerplate code, everything could
be done, but it wasn't trivial.
This commit add a default grabber function that implements the
keybinding API already used by `awful.key` and `awful.prompt`.
It also add syntax candy left and right to make the module "feel"
like a native CAPI object.
Nothing is perfect and some parts, like adding root keybindings, are not
vevy pleasing. However it fulfill its goal when it comes to make
previously non-trivial use case very easy to implement and deploy.
Instead of messing with CMake's environment and having that implicitly
inherited when running a process, explicitly set $SOURCE_DIRECTORY where
required.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tests/run.sh uses awesome-client to actually make awesome run the test.
If awesome-client fails, then the only error message that is printed look like:
== Running /home/travis/build/awesomeWM/awesome/tests/test-leaks.lua ==
Error org.freedesktop.DBus.Error.NoReply: Message did not receive a reply (timeout by message bus)
E: dbus-send failed.
make[4]: *** [CMakeFiles/check-integration] Error 1
To also get the output from awesome, this commit makes failures from
awesome-client non-fatal so that the following shell code can notice the
failure and hopefully print some useful information.
Signed-off-by: Uli Schlachter <psychon@znc.in>
STRICT_TESTS was introduced in commit c22b93963. Some people have setups
where e.g. fontconfig produces warnings. These warnings made the tests
under tests/examples/ fail. The above commit changes things so that
these warnings are ignored by default, unless STRICT_TESTS is enabled.
Commit b5ca8bf937 broke this by making example test failures fatal
again.
Fix this by appending "|| true" to the command to run in case strict
tests are disabled. Thus, all failures from tests/examples/runner.sh get
ignored.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of running the example tests directly from CMake and checking
the results via CMake, the tests are now run through a shell script.
So far, there are too many variables involved for me to easily figure
out how to run this shell script in the building phase instead of the
configuring phase, but at least this commit moves the "actual running"
out of CMake, bringing us a step closer to that goal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a long time, it was deemed overkill and made rc.lua less readable
without the documentation.
However it is now clear that it's handling of unfocusable clients and
general bypassing of both `awful.client.focus.filter` and
`awful.ewmh.activate` filters causes bugs. Fixing them individually
in each instance of `rc.lua` `client.focus = c` would add so much code
that all the clarity provided by not using request::activate would be
burried in boilerplate code.
Fix#2328
This code was attached to mouse::enter in `rc.lua` instead of being part
of the unified request::activate architecture.
There is currently no way to detach this focus filter because it is
generally correct.
Uli Schlachter
mergify[bot]
Emmanuel Lepage Vallee
Uli Schlachter
Mak Kolybabi
Uli Schlachter