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>
Daniel Hahler
Uli Schlachter
Emmanuel Lepage Vallée
actionless
Uli Schlachter
Luke Bonham
getzze
Kevin Zander
morethanoneanimal
copycat-killer
Daniel Hahler
SammysHP