io.open returns nil, an error message and an error code on failure. This
perfectly fits assert which will make the script fail with the error
message. Previously it would fail with "attempted to index a nil value".
Reference: https://www.reddit.com/r/awesomewm/comments/5kyqji/cant_build_git_awesome/
Signed-off-by: Uli Schlachter <psychon@znc.in>
The documentation for CMake's add_custom_command()-command says the
following for USES_TERMINAL:
The command will be given direct access to the terminal if possible.
With the ``Ninja`` generator, this places the command in the
``console`` ``pool``.
The result is that one can see the progress of tests/run.sh, because
messages appear immediately instead of delayed (instead all other
parallel steps are delayed; in practice this means luacheck output
appears only after tests/run.sh is done).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a short text with some hopefully helpful pointers to the top
of the index.html generated by ldoc.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This document is based on the "my first awesome"-page in the old wiki.
Large parts of it are taken almost verbatim from it while others were
handled more freely. For example, instead of referring to the man page
for an overview of the available key bindings, this now mentions Mod4+S.
The "Add widgets"-section is just a todo. The wiki page refers to
Vicious which does not really work for our api documentation. However, I
also didn't want to just drop this part.
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>
When setting a wallpaper, we open a second connection to the X11 server
and create a pixmap there. This pixmap is then used as the wallpaper. We
do this so that we can use a "close down mode" called "permanent". This
means that the X11 server will not free the pixmap after we disconnect,
but keeps it allocated. Setting this close down mode is the last thing
that we do on the setup-the-wallpaper-connection before disconnecting.
However, sometimes things didn't work around. The wallpaper was missing
and trying to query it resulted in errors that basically mean "there is
no such pixmap". Thus, the symptoms say that the close down mode did not
work.
This commit is an attempt to fix this. Instead of just flushing before
closing the connection (sending all outstanding requests to the server),
this commit does a sync, which means it sends a request to the server
and waits for a reply. This guarantees that all previously requests were
handled.
The theory here is like this: We send the SetCloseDownMode-request and
then immediately disconnected. If the X11 server notices that we are
disconnected before handling the SetCloseDownMode-request, the request
would be ignored.
This theory is consistent with the symptoms above and in my local
testing this patch seems to fix things, but since the error only
appeared sporadically, I cannot be 100% sure. Still, it all seems to
make sense to me.
Fixes: https://github.com/awesomeWM/awesome/issues/1276
Signed-off-by: Uli Schlachter <psychon@znc.in>