Once the signals get propagated, it means "manage" will call code before
the metatable is set. If this happens and it sets some properties, they
will perpetually bypass the `awful.client.object` handler.
Given there is some async wibox redraw operations, there is a tiny,
tiny chance the test suite callback will be executed before the
redraw. It has been seen on the CI, so it is not 100% impossible.
Instead of having the default template hardcoded as code, this turns the
template into a descriptive version. This makes it easier to come up
with own templates: Just copy the default template and make a slight
change to it.
No functional changes are intended, but I cannot rule out that I did no
mistakes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
LGI truncates GVariant bytestring instances at the first embedded \0
byte when using .value for "unwrapping". This commit works around that
problem by avoiding the .value API for accessing the image data [0].
Thanks a lot to Will Dietz for finding this problem and for providing a
preliminary patch fixing the problem. That saved me a lot of time [1].
[0]: https://github.com/pavouk/lgi/pull/223
[1]: eecdeb7d46
Signed-off-by: Uli Schlachter <psychon@znc.in>
This starts the switch from our own, semi-broken DBus bindings to using
the sane bindings that Gio provides.
Part-of: https://github.com/awesomeWM/awesome/issues/1093
Signed-off-by: Uli Schlachter <psychon@znc.in>
* Fixed input_passthrough property not being set
In the table of properties supplied to the `wibox` function, you couldn't set the `input_passthrough` property. You could only set it after the wibox was created like this: `my_shlick_wibox.input_passthrough = true`. This commit fixes that and now you can set it in both ways.
When you call `reset_timeout` on a notification with 0 timeout and thus no timer, a nil field error occures.
(can be tested with `awesome-client 'require"naughty".notification{message="TEST",timeout=0}:reset_timeout()'`)
Everywhere else in similar places (even at the beginning of the `reset_timeout`) the `self.timer` field is checked so i guess it was just forgotten there.
This library allows to get a human-readable string describing X11
requests, events, and errors. We now use this library to pretty-print
X11 errors if we get any.
To test this code, I added the following two lines to AwesomeWM so that
X11 errors are generated:
xcb_set_input_focus(globalconf.connection, 42, 42, 42);
xcb_randr_set_output_primary(globalconf.connection,
globalconf.screen->root, 42);
Output without xcb-errors:
X error: request=SetInputFocus (major 42, minor 0), error=BadValue (2)
X error: request=(null) (major 140, minor 30), error=(null) (147)
Output with xcb-errors:
X error: request=SetInputFocus (major 42, minor 0), error=Value (2)
X error: request=RandR-SetOutputPrimary (major 140, minor 30), error=RandR-BadOutput (147)
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is not much good reason why this should be required and making it
optional is almost trivial, as this patch shows.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes test-gravity.lua use the new infrastructure that was
added in the previous commit: Instead of pretending to be a steps-based
test, this is now a direct test. This gets rid of all the useless
wait_a_bit steps that exist purely to satisfy the steps-based test
runner.
This commit makes test-gravity.lua about one third shorter. Also, the
test might run a tiny bit faster, since there is no more timer that
regularly checks if the test is done, but instead it finishes
immediately when the external process finishes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The current _runner.lua expects a table containing steps to be passed
in. However, not all tests look like this. This commits adds an API to
the runner that allows tests to run however they like. They just have to
call run_direct() initially and call done() when they are finished.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Between xcb_grab_server() and xcb_ungrab_server(), XCB's output buffer
might fill up. Thus, the GrabServer request might already have been sent
to the server, but the following UngrabServer request could end up in
XCB's output buffer. There, it might sit around for quite a while and
cause problems.
Since we cannot detect when XCB's output buffer fills up, we just always
flush after generating an UngrabServer request.
Very-likely-Fixes: https://github.com/awesomeWM/awesome/issues/2697
Signed-off-by: Uli Schlachter <psychon@znc.in>
This moves selection_acquire to selection.acquire, selection_getter to
selection.getter and selection_watcher to selection.watcher. The only
user-visible change due to this is that type(selection) is now "table"
instead of "function". If that breaks something for you, tough luck.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
mergify[bot]
Uli Schlachter
Will Dietz
Will Dietz
Adrian Gabriel
Anton Bulakh
Daniel Hahler