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>
Uli Schlachter
actionless
Uli Schlachter
Rastislav Barlik
Emmanuel Lepage Vallée
Daniel Hahler
Daniel Hahler
Reiner Herrmann
Luke Bonham
getzze