This also helps to easier spot failures because of this when looking
at the build matrix.
- Add new check-qa target, to be run only once.
- Add explicit check-unit-coverage target, used with DO_COVERAGE.
This function was iterating over a table with pairs() to generate output (the
sample theme file). Since pairs() does not guarantee any iteration order, this
lead to a different order each time this file was generated. This is, for
example, visible in the diffs in the generate api documentation repository.
Fix this by using a self-made iteration function which behaves like pairs(), but
guarantees an iteration order sorted by keys.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of using Xlib for parsing resource files, this now uses the
dedicated xcb-based library that is meant for exactly this task.
Fixes: https://github.com/awesomeWM/awesome/issues/1176
Signed-off-by: Uli Schlachter <psychon@znc.in>
Via this, I can set HEADLESS=1 in my wrapper-GNUMakefile that I use and
"make check" will no longer open a new window that gets in my way.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similarly to what we do with the client list, this signal is emitted
whenever the list of screens changes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in luaA_client_swap() is incorrect, because
luaA_object_emit_signal() already pops the arguments to the signal.
Still, the code here tried to remove the arguments from the Lua stack
again, thereby corrupting the stack (removing more items than there are
in the stack).
Normally, popping more things from the stack than it has entries
silently corrupts the Lua stack. Apparently this doesn't necessarily
cause any immediate issues, because this code has been broken since nine
months and no one noticed. This mistakes was introduced in commit
55190646.
This issue was only noticed by accident. Thus, this commit also adds a
small integration test that exercises this bug. This test catches the
issue, but only on Travis, because there we are building our own version
of Lua 5.3 and that one has assertions enabled.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The usual "a or b"-trick to simulate C's ?:-operator does not work when
"false" is a valid value. Fix the code to handle this correctly and add
a short unit test which would have caught this problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We already have a variant of this function for transforming an actual
matrix. This adds the corresponding static factory.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of doing Linux-specific magic with error codes and trying to
read the first byte of a file, just use Gio to check if a file exists
and is readable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When adding callbacks as a `callback` entry in a property, the callback
is run by `awful.rules`, because it does `c.callback =
result_of_function`. This is obviously not intended. Also, this causes
the callbacks to run twice, because the code already handled this
`callback` property specially.
Fix this by just not merging callbacks with the normal rules at all.
Fixes: https://github.com/awesomeWM/awesome/issues/1159
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of hardcoding the list of generated doc files as dependencies to
ldoc, we jump through some hoops to compute this dynamically.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A while ago, we made errors from ldoc fatal by default. Then a new ldoc
release appeared and caused problems for all of our users, because
awesome failed to work.
This patch reverts the previous fix so that we ignore ldoc warnings by
default again. However, to catch ldoc warnings on Travis, another
ldoc-building-target is added that fails on warnings. This new target is
included in our "check" target.
This fixes the intend of issue #1098 ("Users with ldoc version X cannot
build awesome"), but it does not actually employ the solution proposed
there ("Blacklist those ldoc versions"). Still, since this fixes the
intend of the issue, I count it as fixed.
Fixes: https://github.com/awesomeWM/awesome/issues/1098
Signed-off-by: Uli Schlachter <psychon@znc.in>
At the beginning of every main loop iteration, we check for new events
from the X11 server. However, it's theoretically possible that during a
main loop iteration new events arrive and are read by libxcb into its
internal buffer. This would mean that the fd connected to the X11 server
is not readable and thus we do not wake up to handle these events.
Handle this by checking for pending events before calling poll(). If a
new events appears, we set the timeout for poll() to zero and will then
handle the new event in the following iteration of the main loop.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallée
MoreThanOneAnimal
Daniel Hahler
Uli Schlachter
Daniel Hahler
actionless
Uli Schlachter