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>
I am no longer sure why I added this file. It doesn't really belong into
the awesome source code. It is better suited to be added to our web
page, I think.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I really try to avoid doing this, psychon too, but enough is
enough. We don't have a solution and I would rather add more
tests that work than keeping a test that keep "failing" just
to remind us it's there.
Cleanup and point to the GitHub page for the recent contributors.
Some older contributors don't have GitHub accounts, so are
invisible, so I left the old list intact.
This commit doesn't add any useful documentation, but adds
previously hidden documentation variables. It can be the basis
of a better layout documentation.
Fix#1246
We have many places where we are sending an XCB request and expect an
answer where the protocol guarantees that no error can occur and we are
sure to get an answer. However, for example if the X11 server crashes,
these places can still fail. This commit tries to handle failures at all
these places.
I went through the code and tried to add missing error checking (well,
NULL-pointer-checking) to all affected places.
In most cases these errors are just silently ignored. The exception is
in screen querying during startup. If, for example, querying RandR info
fails, we will fall back to Xinerama or zaphod mode. This is serious
enough that it warrants a warning. In most cases, we should exit shortly
afterwards anyway, because, as explained above, these requests should
only fail when our connection to the X11 server breaks.
References: https://github.com/awesomeWM/awesome/issues/1205#issuecomment-265869874
Signed-off-by: Uli Schlachter <psychon@znc.in>
The function that is documented as awful.wibox.stretch is deprecated,
because it was removed (that's not a deprecation, is it?!?). For the
replacement, we used "@see stretch". However, LDoc was randomly
resolving this reference to awful.wibar.stretch (good) or
awful.wibox.stretch (bad; the see points to the element where it
appears).
Fix this by spelling out the "full name" of the function in the @see.
Related-to: https://github.com/awesomeWM/awesome/issues/834
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Uli Schlachter
Emmanuel Lepage Vallée
Enric Morales
Daniel Hahler