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>
Ever since these files were added, these problems existed. I have no
idea what alt_fg is supposed to mean, but since a value of nil is
apparently ok, I just pass in nil directly.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Up to now, a drawable always figured out the screen that it is on by
looking at its position. This causes memleak-like problems with wibars:
A wibar has a screen assigned, but its underlying drawable will end up
referring to another screen. Via this, we were managing to build a long
reference chain of screens and drawable that meant that none of the fake
screens that our test suite added could be garbage collected.
To fix this, add wibox.drawable._force_screen(s). After this function is
called, the normal screen detection based on the position is skipped and
instead the given screen is always used. This breaks the above reference
chain and things become garbage-collectable.
Also, this chains the drawable to the life time of the screen: When the
screen becomes invalid (.valid == false), the drawable will stop
redrawing.
Fixes: https://github.com/awesomeWM/awesome/issues/1237
Signed-off-by: Uli Schlachter <psychon@znc.in>
These files do not need to be executable and the commits which made
these executable apparently only did so accidentally (Commits
37684abe33 and bfc6065ad9).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Daniel Hahler
Daniel Hahler
Uli Schlachter
Uli Schlachter
Enric Morales