Step 1 starts a client and uses awful.rules to move it to a not-selected tag.
Because this rule still has focus=true, this calls awful.ewmh.activate() via the
request::activate signal. This function makes the client urgent because it is on
a not-selected tag.
Step 3 does the same thing, but also uses switchtotag=true. Now
awful.ewmh.activate() doesn't make the client urgent because it successfully
focused this client. However, the test was wrongly assuming that the client
became urgent (copy&paste error? I don't know).
The fix is of course not to require the client to become urgent.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently, an error in the default config in the right place isn't noticed. Fix
this by doing two things:
- Also grep for "error" (this catches runtime errors with a stack trace)
- Make _runner print a "success" message at the end and also grep for that
Fixes: https://github.com/awesomeWM/awesome/issues/689
Signed-off-by: Uli Schlachter <psychon@znc.in>
Both the test runner and the wibox use gears.timer.delayed_call(). The test
runner uses this to call steps and the wibox uses it to trigger redraws. When
running under LuaCov, the Lua code becomes slow enough that the wibox didn't
redraw yet when the leak check is run. This causes the check to fail, because
the client is still referenced by the tasklist and thus cannot be garbage
collected.
Fix this by waiting one more iteration before running the leak check.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This opens xterm, closes it and makes sure that the client object representing
xterm is GC'able at the end. The test will fail currently.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The benchmarks in tests/test-benchmark.lua have two modes. When CI=1 is set in
the environment, only a "quick" and less exact test is done. Otherwise, a slower
and more exact measurements is taken. This was added so that we do not waste CPU
time on travis.
However, most of the time the user running "make check" doesn't want exact
measurements either. So instead of only being quick when CI=1 is set, this
commit changes the logic to always being quick unless BENCHMARK_EXACT=1 is set.
Additionally, a message is printed next to the benchmark results so that the
user is reminded to set this var if the measurements should actually mean
something.
Signed-off-by: Uli Schlachter <psychon@znc.in>
While setting up an environment to run the integration tests in, the run.sh
script uses sed to generate versions of several files that refer to the
not-installed version of files. One of these needs to replace the call to
beautiful.init().
Before commit 20c9723c5b, the corresponding line was:
beautiful.init("@AWESOME_THEMES_PATH@/default/theme.lua")
Now this wants to find and replace the following:
beautiful.init(awful.util.get_themes_dir() .. "default/theme.lua")
To handle both versions, this commit adds some wildcards to the sed-expression
so that any line containing a call to beautiful.init is found and replaced.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Having many arguments can easily get confusing and hard to understand. This
commit uses a table instead so that we have names that identify what each
callback does.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When using `spawn` without startup notification support, the
`startup_id` property on the client should be nil.
This adds rxvt-unicode to the Travis build, because it supports startup
notifications, but xterm does not. We should replace xterm with it in
the existing tests then later.
* This commit add a new module to avoid a (4 level) loop dependency
* It is now possible to call awful.spawn() with a table of properties
* awful.rules is used to execute the rules.
* Everything is public to allow alternative workflow modules such as
Tyrannical to use their own callback implementation.
This makes it possible to add something similar to a __index / __newindex
metamethod to all our C objects. Based on this, Lua can then easily implement
arbitrary properties on our capi objects.
I have no idea why this needs collectgarbage() to be called twice.
On the other hand, I can explain the change in tooltip.lua. Lua 5.2 introduced
"ephermeron tables". This means that in the following sitation, lua 5.2 can
collect the entry from the table, while 5.1 keeps the entry alive, because the
table has a strong reference to the value and that in turn has a strong
reference to the key:
t = setmetatable({}, { __mode = "k"})
do
local k = {}
t[k] = function() print(k) end
end
collectgarbage("collect")
print(next(t, nil))
To handle this incompatibility, this commit just removes the whole indirection
through the module-level variable "data".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently some of the last commits speeds up create_wibox() a lot. This
highlights that this is a bad test: After creating thousands of wiboxes, awesome
needed 15 seconds to draw all of them and in the end some dbus timeout aborted
the test run.
However, it's irrelevant how quickly we can create wibox. The interesting number
is how quickly we can display a new wibox. Thus, this commits changes the code
so that it also measures the time that is needed to update the wibox. This way,
we don't accumulate a huge number of pending repaints and everything's fine.
Some results (but there is nothing to compare this with):
create&draw wibox: 0.0373947 sec/iter ( 28 iters, 1.59 sec for benchmark)
update textclock: 0.00198174 sec/iter (515 iters, 1.937 sec for benchmark)
relayout textclock: 0.000614439 sec/iter (1710 iters, 1.051 sec for benchmark)
redraw textclock: 0.00116882 sec/iter (865 iters, 2.962 sec for benchmark)
tag switch: 0.000705579 sec/iter (1498 iters, 3.703 sec for benchmark)
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit does two things: It gets rid of the reference to the layoutbox that
the default config created and it changes the widget dependency cache to not
keep widgets alive unnecessarily.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Again, instead of directly connecting to various signals for updating a
tasklist, this commit changes the code so that there is just a single, global
connections and based on this a weak table with all tasklist instances is used
do the updates.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similar to what the previous commit does for layoutboxes, this changes the code
for the taglist so that there is only a single, global connection to the various
signals and these update all taglists via weak tables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This (ab)uses the integration tests to run a benchmark. This currently only
measures wibox drawing performance. To avoid wasting CPU-cycles, this does only
a quick run under travis while on "normal" runs the function under test is
executed in a loop to improve the precision of the measurement.
This benchmarks hopefully allow to optimize things in a clear fashion instead of
things like "it feels faster to me".
Results when run against the previous commit:
== Running test-benchmark.lua ==
create wibox: 0.0788958 sec/iter ( 13 iters, 1.103 sec for benchmark)
update textclock: 0.019493 sec/iter ( 56 iters, 2.507 sec for benchmark)
relayout textclock: 0.0160725 sec/iter ( 63 iters, 1.029 sec for benchmark)
redraw textclock: 0.0015601 sec/iter (647 iters, 1.875 sec for benchmark)
W: awesome: a_glib_poll:291: Last main loop iteration took 6.593912 seconds! Increasing limit for this warning to that value.
Results right before the new widget layouts were merged (commit 52154d0f15):
== Running test-benchmark.lua ==
create wibox: 0.0782874 sec/iter ( 13 iters, 1.095 sec for benchmark)
update textclock: 0.00736755 sec/iter (136 iters, 1.346 sec for benchmark)
W: awesome: luaA_dofunction:77: error while running function
[...]
error: /home/psychon/projects/awesome/build/lib/gears/object.lua:30: Trying to emit non-existent signal 'widget::layout_changed'
Closes https://github.com/awesomeWM/awesome/pull/451.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This tried to use awful, but didn't load awful itself. Kids, this is why you
should make your variables local!
Signed-off-by: Uli Schlachter <psychon@znc.in>
When using Xephyr, this already starts the server with -noreset, but for Xvfb we
also need this flag. Without this flag, the DPI value that is set via xrdb gets
lost at server reset.
This wasn't a problem before commit 6d4837a53a. That commit moved the launch
of the dbus session after the setting of the DPI. So previously, waiting for
server startup was half broken (the dbus session already tried to connect to the
server to check for when it shuts down), but due to this no server reset
occurred and thus the DPI was correctly applied. After this commit, the server
immediately resets after xrdb is done setting the DPI and the value set is lost.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This factors out a function wait_until_success that runs some command until it
succeeds (with a timeout) and uses this function in the two places where this
was already done before.
Note that this removes the "kill -0" trick for early exit again and instead will
use the timeout in case awesome dies during startup.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When this script is not run under Travis, it will prepare a temporary config
file and a theme file that point to the files that were not yet installed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code does some dances with xrdb to ensure that the server finished starting
up. However, before this it already tries to access the server via dbus-launch.
Since nothing uses dbus in this part of the code, we can just move this down.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I tried calling this script with "tests/foo.lua" as an argument, but it actually
expects "foo.lua" since it changes into the appropriate directory itself.
Because this file does not exist, "cat $f | awesome-client" failed and thus this
whole script just hung (the test runner was never actually started).
Fix this by testing for the test-file to exist before trying to run it.
Signed-off-by: Uli Schlachter <psychon@znc.in>