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>
This commit adds a .txt file next to each example test that generates a
text output. This text file contains the expected output and it is an
error if the actual output does not match the expected output. This
means that we no longer have to run the example tests before we can
expand all the @foo@ expressions that occur.
While touching this, I also fixed some typos and unexpected newlines in
the tests' output.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since last year luacheck change, trailing spaces are no longer
allowed. This caused all documentaiton examples that used them
as a way to mark newlines to look plain wrong.
This commit add an explicit flag to make longer examples more
readable.
* Add a FOLLOW_SYMLINKS so Awesome 3rd party module can share the
awesome test infrastructure by adding themselves as symlinks in
`lib/`, `tests/` and `tests/examples` and otherwise use AwesomeWM
Travis config.
* Add an option to add examples to the C documentation. Previously only
Lua functions could be documented using this framework.
This allows to figure out if a test will generate an image without
having to run it. The long term plan for this is to run the tests during
compiling ("make") and not during configuring ("cmake"). Since the list
of files to e.g. install needs to be known during configuring, this
commit is a necessary step in that direction.
Signed-off-by: Uli Schlachter <psychon@znc.in>
No currently existing test produces a PNG image, so why do we even check
for such an output file?
I did 'rm -rf build && make -j9 && cp -r build /tmp', then applied this
patch, and then did another 'rm -rf build && make -j9'. According to
diff, the resulting directories are basically the same (except for lots
of timestamps and some non-determinism in CMake).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows to e.g. easily run awesome from source (for an hour) via
TEST_TIMEOUT=42d tests/run.sh /dev/null.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not really a test. It just starts xeyes and sees if anything
explodes.
However, the reason for this test is to stabilise code coverage.
Apparently, Gtk(?) sometimes creates shaped windows. This had the effect
that codecov always reports random changes to code coverage, depending
on if this specific test run saw any shaped client windows or not.
Thus, by explicitly adding a test that runs a shaped client, hopefully
these random fluctuations disappear.
Hopefully-fixes: https://github.com/awesomeWM/awesome/issues/1975
Signed-off-by: Uli Schlachter <psychon@znc.in>
This should help with covering the methods for detection/fallback during
tests.
Ref: https://github.com/awesomeWM/awesome/pull/2109#issuecomment-346224956
Uses xrdb -q to check for X server being available.
Ignores the following warning:
> W: awesome: beautiful: can't get colorscheme from xrdb (using fallback).
- install luacov.runner in tests/_runner.lua.
- use Lua's `dofile` to execute the test files, which will give us
coverage for them.
- CMakeLists.txt: revert DO_COVERAGE env injection
- revert cd: make f absolute if not in source_dir
If a tag is specified by name, but no such tags exist, awful.rules would
cause an error (attempt to index a nil value). Fix this and add a test
for this case.
Fixes: https://github.com/awesomeWM/awesome/issues/2087
Signed-off-by: Uli Schlachter <psychon@znc.in>
LUA_COV_RUNNER is used with `add_custom_command` for the command to
generate the images, and AWESOME_THEMES_PATH should be set there.
Since LUA_COV_RUNNER is used also with `execute_process` there is no
need for `set(ENV …)` anymore.
During build svg images of the calendar widget are generated, which
differ based on the current date.
By honouring the environment variable SOURCE_DATE_EPOCH, which is
set by distributions during build, a deterministic date can be used
at build time while keeping the normal behaviour during runtime.
See also: https://reproducible-builds.org/specs/source-date-epoch/
This still runs all the tests in the configure phase, since the tests
report back what output file (png/svg/none) will be generated.. :/
This could be improved by having this table in CMakeLists directly, or
by having a callback into the tests that only reports back that
information. The latter would still execute all the tests (via a Lua
process).
Adds an explicit check-examples target.
This adds a new argument to awesome.spawn that can be used to specify
the environment of the spawned process.
Signed-off-by: Uli Schlachter <psychon@znc.in>
project() automatically sets the PROJECT_NAME variable. Thus, when this
CMake code is run due to being included by awesome, this commit has no
effect.
When this CMake code is run on its own, CMake will no longer check for a
C and C++ compiler.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was changed in ec9a981d for no good reason, and using a temporary
file removes the requirement to restore it on exit.
And it is necessary in case the original file is not writable (e.g. in
case of a read-only Docker mount).
- add colors
- count test files
- display error summary
- filter out a_dbus_connect warnings and "Test finished successfully." message
- print current step with VERBOSE=1
- kill clients at the end of tests in an extra step
A test counts as having failed if it prints any error. However, the
search path can very well contain non-existing directories which are not
a problem. Thus, handle this by monkey-patching gears.debug.print_error.
Ref: https://github.com/awesomeWM/awesome/pull/1872#issuecomment-311224439
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test runs into an lgi bug that causes awesome to segfault. Work
around this by just disabling the test where needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This does not actually test anything. It just makes sure that the code
runs. A proper test still seems to need some time and some hacks, but
this basic test is enough to check that the menubar does not cause any
Lua errors.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Just re-arranging on every focus change would cause useless/needless
re-arranges (which have no effect except to waste CPU time). Thus, this
adds a special (undocumented) flag on layouts that makes sure that a
rearrange occurs when the focus changes.
Fixes: https://github.com/awesomeWM/awesome/issues/1799
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the border width changes, we move the client according to its
gravity. This can cause problems with the following code. Fix this by
restoring the original border width again, which undoes the move.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a C program which tests if the window manager handles
gravities correctly. This program is loosely based on metacity's
test-gravity.c, but completely rewritten and this version does automatic
tests instead of allowing the user to perform testing by hand.
By having this as a self-contained C program, it is possible to compare
awesome's behaviour with the behaviour of other WMs.
In my testing, only metacity and awesome pass this test. This is not
that much of a big surprise since awesome was fixed in
https://github.com/awesomeWM/awesome/pull/505 to work correctly with
metacity's test-gravity.c. However, I am surprised that e.g. Fluxbox
gets this wrong.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There are some cases where a client's floating state "silently" changes.
For example, a fullscreen client will be considered floating. However,
even though c.floating changes its value in this case, we did not emit
the property::floating signal.
Fix this by explicitly tracking the "implicitly floating" state. When
some property that influences this "implicitly floating" state changes,
we update it and if a client which was not explicitly assigned a
floating state observes a change in this value, property::floating is
emitted.
This was tested by running a terminal and two xeyes in a tag with a
tiling layout where awful.ewmh was patched so that clients do not change
their geometry when fullscreening or maximizing. It was observable that
after this patch e.g. the titlebar and the tasklist update to show the
floating state of the client which became implicitly floating due to
being maximized.
Fixes: https://github.com/awesomeWM/awesome/issues/1662
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a while now we had our code coverage tools tell us that the coverage
for one line of code fluctuated. Sometimes it was being executed and
other times it was not. This is useless noise.
I think what is happening here is that the coverage depends on the order
of iteration over a table. Either the tooltip that is being created was
first made visible and then it text changed, or things happened in the
opposite order.
Fix this by doing this by explicitly changing the tooltip's text while
it is surely visible.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously it would print a table which would include the memory
location where the table was stored. Thus, this produces a different
result on every build.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tests/run.sh waits for awesome to exit via tail's "--pid" option. This
makes tail check once per second if the process still exists and if not,
tail will exit. However, the default of "once per second" causes lots of
wasted time for us.
This commit adds the argument "-s 0.1" to tail which makes tail check
once every 0.1 seconds. This commit changes the time that "tests/run.sh"
runs on Travis from about 60 seconds to about 35 seconds, which is a big
improvement.
Closes: https://github.com/awesomeWM/awesome/issues/1374
Signed-off-by: Uli Schlachter <psychon@znc.in>
When the keyboard layout is modified via xmodmap, each single "change"
(line of input to xmodmap) causes an "the keyboard configuration
changed"-event to be sent. Awesome reacted to each of these events by
reloading the keyboard layout. Thus, awesome reloaded the keyboard
layout a lot and appeared to freeze.
Fix this by asynchronously update the keyboard state: When such an event
comes in, instead of reloading things immediately, we set a flag which
makes us update the state at the end of the main loop iteration. This
means that many events still cause only a single (or at least few)
re-quering of the layout. Thus, a lot of time is saved.
This commit removes the argument to the (undocumented!) signal
xkb::group_changed. Previously, the argument was the active group
number. Since this argument was unused and I'm lazy, I just removed it.
The alternative would be that it might be visible to Lua that some "the
active group changed"-events are dropped.
Fixes: https://github.com/awesomeWM/awesome/issues/1494
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
This makes the scroll and only_on_screen widgets appear in the widget
lists. The examples are not really helpful, but Elv13 told me to add
them. Also, only_on_screen is in awful.widget, but now something in
tests/examples/wibox/container refers to it...
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit add an option to shim the whole wibox module when
running multi-screen tests. This is intended to lower the test
runtime when coverage is enabled.
In theory, most of that code is already covered by the
test-screen-changes suit.
This makes the coverage builds about twice as fast. This is
necessary because there is a large number of timeouts due to
limited resources on the Travis build system.
And stop listening to property::geometry, it's no longer needed.
This also remove messing up the border without saving it
somewhere. The concept is sound, but not the implementation.
In Gtk 2, the "first" argument to set_geometry_hints() is not optional.
However, this code does not provide any argument here. Improve the error
message in this case by checking for Gtk 3.
Reference: https://github.com/awesomeWM/awesome/issues/1495
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows for `DO_COVERAGE=1 make check` with local tests (where
`CI=true` is not given).
It uses the new environment variables to configure the default theme,
instead of creating a temporary config/theme.
- Execute the tests without compiling, and don't mess with the source
files when coverage is enabled.
This ensures that the coverage report lines are correct.
This disables the doc tests, as their results would be unused.
Hack: it still expands macros on util.lua, because of
`util.get_themes_dir()` and `util.get_awesome_icon_dir()`, which might
be moved later. Ref:
https://github.com/awesomeWM/awesome/pull/1239#discussion_r93828178.
- ensure that BUILD_APIDOC and DO_COVERAGE are not used together
- awesomeConfig.cmake: add DO_COVERAGE as an option
- Travis: only install codecov with DO_COVERAGE=codecov
- Travis: do not use set -v; use set -x with DO_COVERAGE
- do not use trailing slashes with dirs in tests/examples/CMakeLists.txt / .luacov
- Use latest luacov (0.12.0-1) again
This reverts parts of 4cc6a815.
I think it is better to fix any failure that 4cc6a815 tried to work around.
- Travis: simplify/fix require('luacov') for functionaltests
- tests/examples/CMakeLists.txt: resolve ../.. in SOURCE_DIR
- tests/examples/CMakeLists.txt: add DO_COVERAGE to env
- Cleanup/simplify .luacov: work with SOURCE_DIRECTORY alone
- tests/run.sh: pass through / set SOURCE_DIRECTORY when running awesome
- tests/run.sh: resolve source_dir
- use DO_COVERAGE from env only
X11 does not allow to resize a window to size 0x0. Also, there are some
possibilities of integer overflows in our case. We tried to handle this
already, but there was a loop-hole: If the too-small-value is only
produced after applying size hints, then this was not caught.
Fix this by applying size hints before checking if the resulting size is
valid. However, this means some check needs to be duplicated to handle
the possibility of integer underflows while applying size hints.
Helps-with: https://github.com/awesomeWM/awesome/issues/1340
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a new argument to the test client spawning function that will
make the test client window set a resize increment property.
The API here is starting to a bit ugly, but since this is not any user
facing API, that should not be a problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Otherwise commented lines look like ---- My comment
instead of -- -- My comment. This wasn't a problem before the
intentation fix commit, but it is now.
Commit a944636c02 "bashified" tests/run.sh for some reason.
Afterwards, commit 4abd820051 fixed some of the fall-out.
However, there is still a problem left.
We have "set -e" in this script. Thus, whenever some command exits with
status 0, the script abort. When the variable errors is zero/unset, the
command "((errors++))" has exit status zero. Thus, this instruction
caused the shell script to abort. This was not intended.
Fix this by using "((++errors))" instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, the test runner used a timer which fired every 0.1 seconds
to "do its thing". Many of these waits seem unnecessary.
This commit makes the test runner wait 0 seconds for the first call of a
step function. Only following calls will have a timeout of 0.1 seconds
applied.
A full run of the test suite (tests/run.sh without further arguments)
took about 100 seconds before this change. After this change, we are
down to 60 seconds. This is almost factor two faster! (Well, five thirds
is the exact number, so factor 1.66)
(The numbers are best out of three runs. The "before" number is rounded
down while the "after" number is rounded up.)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we got the following unhelpful error message:
tests/_client.lua:98: bad argument #2 to 'assert' (string expected, got
userdata)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This uses DOC_HIDE magic in the actual test code, except for the
template.lua files which do not have it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The following commits will add DOC_HIDE uses that are not at the end of
the line, but the beginning. Hence, drop the requirement that it appears
at the end of the line and change the ".+" at the beginning into ".*".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Copy-paste-y I was checking for the wrong result. Another unrelated
problem with the test runner caused me to miss this. Sorry!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes a duplicate test and moves some "spawn with empty string as
argument" up to the long list of similar tests (and adds error
checking).
I do not see the point of the assert(#client.get() == 0) and so it was
just dropped.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Commit 5e6a893 broke error handling in awesome.spawn(): Instead of
returning an error message, it would just return its last argument.
This commit fixes that, removes some not-so-helpful warnings, and adds
lots of tests for this code.
Fixes: https://github.com/awesomeWM/awesome/issues/1281
Signed-off-by: Uli Schlachter <psychon@znc.in>
Locally I got this, where only two xterms were opened.
```
% tests/run.sh test-awesomerc.lua
awesome_log: /tmp/tmp.ToAKs6Gw4J/_awesome_test.log
== Running test-awesomerc.lua ==
Error: timeout waiting for signal in step 1/11 (@20).
===> ERROR running test-awesomerc.lua! <===
Error: timeout waiting for signal in step 1/11 (@20).
There were 1 errors!
```
This is a partial revert of commit 7901a1c647. The end result is the
same, but the change from that commit is reverted and instead the same
thing is done in a different way.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Ever since these files were added, these problems existed. I have no
idea what alt_fg is supposed to mean, but since a value of nil is
apparently ok, I just pass in nil directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I really try to avoid doing this, psychon too, but enough is
enough. We don't have a solution and I would rather add more
tests that work than keeping a test that keep "failing" just
to remind us it's there.
Previously, the API to set the data that should be displayed was
:set_data(t) where t is a table. This table has the labels to use as its
keys and the numbers as its values. With this API, it was not possible
to influence the order in which the "pie pieces" were drawn.
This commit adds and uses a new API called :set_data_list(t). Here, t is
a table with integer keys and tables as values, thus one can iterate
over this with ipairs() and the order is well-defined. The tables used
as values contain the label as their first entry and the number as their
second entry.
Fixes: https://github.com/awesomeWM/awesome/issues/1249
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test has a list of "things" that should be present in the output. This
table is iterated over via pairs(), which means that the output is
non-deterministic and the order of the entries is basically random.
Fix this by using ipairs() to get a deterministic iteration order. This requires
some slight change to the table that is iterated over.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This printed a table. This will make Lua print the address of the table and
hence the output of this test was non-deterministic.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There we go again... When hitting a slow CI node, there is again
timeouts when doing the multi-screen tests. As no solution to
bug leading to this has been found, the only thing to do is
increase the timeout.
Hopefully this commit will be reverted soon.
Spawn callbacks were never invoked when no startup-notification-rules were
given. This commit fixes the code so that "startup done" callbacks are also
called when no rules were given.
Fixes: https://github.com/awesomeWM/awesome/issues/1218
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>
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>
The default config had tables like mywibox and mywibox[s] was the wibox
that is visible on screen s. When a screen is removed, nothing cleans up
these tables and so the screen and the wibox could not be garbage
collected. The same applies to the layoutbox, taglist etc.
This commit removes the global mywibox table and instead saves it as a
property on the screen. This way, the screen is not explicitly
referenced and when it is removed, the screen, its wibox and all of its
widgets become unreachable and can be garbage collected.
This commit also updates the docs and the tests that referenced things
(mostly the wibox) via mywibox[s] to now use s.mywibox.
Fixes: https://github.com/awesomeWM/awesome/issues/1125
Signed-off-by: Uli Schlachter <psychon@znc.in>
The new client is hopefully faster. Why, you ask?
Instead of spawning a new Lua process each time a test asks for a new window,
there is a "daemon process" which gets commands to open new windows from its
standard input. That way, Lua doesn't have to load LGI all the time and lots of
pointless work is skipped. The daemon process exits when its stdin is closed and
thus should automatically exit when awesome exits.
Fixes: https://github.com/awesomeWM/awesome/issues/1089
Signed-off-by: Uli Schlachter <psychon@znc.in>
This test changes the mouse cursor's position and afterwards has an
assert that checks something on the tooltip. This really looks a lot
like it expects the mouse cursor's position to be already updated and
its enter and leave events to be handled. However, this is now how
things actually work.
Fix this by moving the assert into its own step, so that in between the
normal main loop runs.
Signed-off-by: Uli Schlachter <psychon@znc.in>
run.sh waits for awesome's startup to be done by having awesome execute "return
1" via its dbus interface. However, by default dbus has a 25 second timeout
before it fails a dbus-send invocation. This defeats the purpose of this
exercise.
So instead of using awesome-client, this commit makes the code use dbus-send
directly and specifies a relative low reply timeout (which should still be
plenty so that this doesn't erroneously fail).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The timeout utility guarantees an exit code of 124 when the process died due to
timeout. Since awesome only ever exits with 0 or 1, we can use this to reliably
detect timeouts and print a matching message.
Signed-off-by: Uli Schlachter <psychon@znc.in>
coreutils provides a timeout command. Use that instead of (badly) inventing our
own version of it. This "timeout" command seems to be new. Let's hope everyone
has it and think about alternative solutions only when needed.
Fixes: https://github.com/awesomeWM/awesome/issues/1075
Signed-off-by: Uli Schlachter <psychon@znc.in>
When awesome exits with a non-zero code, this is something interesting that we
should log. Do so.
The "set +e" / "set -e" dance is required so that we do not abort because the
wait builtin returns a non-zero code.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This script runs under "set -e", so any command exiting with a non-zero status
makes it abort. However, we do not care about failures from grep to find
anything, so handle that case gracefully.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit: When we are GC'ing an object, we clear its metatable, since
otherwise crashes could occur in various places. This means that if someone
tries to use such an object, they get an unhelpful error message like "attempt
to index userdata object" and they don't understand what the problem is. Also,
this means that foo.valid does not actually work after GC.
This commit changes this behaviour. Instead of setting an empty metatable, we
now create a metatable with an __index and __newindex method. These metamethods
produce better error messages that they sat the underlying object was already
garbage collected. Better yet, the __index metamethod makes foo.valid be false
instead of causing an error, so that the existing machinery for detecting
invalid objects continues to work.
This commit also adds a functional test that verifies this behaviour.
Signed-off-by: Uli Schlachter <psychon@znc.in>
To ensure that some features such as SNID rules work, we need
to ensure that the screen isn't set by other code paths. Only
a single algorithm can be executed for the screen. As soon
as many algorithms are executed on events such as "manage", it
will most likely regress again.
This commit make sure of that by disabling the default normal source
of c.screen. After that, any other c.screen changes can be
considered bugs.
The code was written so that it assumes that disconnecting the last signal also
removed the corresponding entry in the signal array. This lead e.g. to an
index-out-of-bounds access in some cases.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The "test launching client on a specific screen" suit is very slow.
However, it is also necessary to avoid issues such as #1069 or #154
from regressing again.
This is a temporary fix until a faster test client "daemon" is
developped.
While testing using "the real deal" and with all the tests would be
better, it would add a lot of complexity to the testing framework.
This module generate multiple multi-screen scenarios and some obvious
issues that they can cause. Over time, as more steps are added, it
will provide "good enough" testing for multiple screens.
Individual test suits can require() this utility to replicate their
steps for each multi-screen scenarios.
This uses the new support introduced in f0f31bc305 in the docs and in
tests/run.sh, removing an useless use of cat/echo.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The build is no longer aborted when one of the "example tests" produces a
message on stderr. However, on Travis this requirement is still made. This
should catch "bad errors" via Travis while not breaking the build for users.
Fixes: https://github.com/awesomeWM/awesome/issues/821
Signed-off-by: Uli Schlachter <psychon@znc.in>
Running the tests sadly takes much to long. Since I don't have a good idea what
to do about this (I'd like to run all tests in a single Lua process, but that
doesn't seem to be possible easily), instead let's just make it more explicit
what is being done. This commit prints a message for each test that is being
run.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Now that tests are no longer scanned for recursively, the hack of passing values
back and forth via the environment is no longer needed and can be removed.
While at it, this also exchanges the "useless use of regex" for an explicit
string replacement.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of recursively walking the directory tree, this commit makes the code us
GLOB_RECURSE to find all files and then handles them on after another.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The namespace of e.g. "tests/examples/awful/mouse/coords.lua" is "_awful_mouse".
This is purely based on the path of the file.
Previously, this was computed while recursively scanning the directory tree.
This commit instead moves this to an extra function that handles this task.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, while recursively scanning the directory tree, the code in here also
scanned for template.lua files and remembered the latest one it found. This
commit adds a function which finds the right template.lua for a given file name,
making this search explicit and easier to understand.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There was a problem that the examples were considered to have failed as soon as
they produced any kind of output, but there were legitimate cases of warnings
being printed that triggered these checks. Commit 4819be4f4f used a
regular expression to detect and ignore this warnings.
This commit reverts the above commit and instead silences the warnings by
monkey-patching the function that prints the warnings into a no-op.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The requirement to call add_signal() was added to catch typos. However, this
requirement became increasingly annoying with property::<name> signals and e.g.
gears.object allowing arbitrary properties to be changed.
All of this ended up in a single commit because tests/examples fails if I first
let add_signal() emit a deprecation warning.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There was a race with autofocus. To overcome this, add another step that tests
that moving the client back to a visible tag and focusing it updates
_NET_CURRENT_DESKTOP. Afterwards, we kill the client so that it can no longer
interfere.
Signed-off-by: Uli Schlachter <psychon@znc.in>
As the documentation generation insert increasingly large ammount
of code into the lua files, the coverage data is getting less and
less accurate. This try to fix this by only collecting such data
after the `configure_file` calls are done.
kill is a wrapper around the POSIX kill() function and unix_signal is a table
that maps signal numbers to their names and signal names to their numeric value.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently, there is such thing as not leaking enough...
Also try to clear the widgets from mywibox. This seem to help.
Time will tell.
Fixes#914, unfixes #808
Currently, tests/run.sh expects the directory layout that our wrapper Makefile
sets up before running CMake. This commit adds support for any other directory
configuration as well.
Signed-off-by: Uli Schlachter <psychon@znc.in>
GDK_SCALE=1 is needed to overwrite other settings that people might have which
would make geometry-related tests fail.
NO_AT_BRIDGE=1 gets rid of the following message that I am seeing:
** (lua:8321): WARNING **: Error retrieving accessibility bus address:
org.freedesktop.DBus.Error.ServiceUnknown: The name org.a11y.Bus was not
provided by any .service files
Signed-off-by: Uli Schlachter <psychon@znc.in>
Any clients with these tags end up somewhere random (the first tag on the first
remaining screen). This certainly can be improved in the future, but at least
this is a start.
Signed-off-by: Uli Schlachter <psychon@znc.in>
GtkApplication does magic like ensuring that the application ID is unique and
there is only a single instance of each application running. We don't want nor
need that for the tests.
Signed-off-by: Uli Schlachter <psychon@znc.in>