Without this fix, children of i3bar would inherit the file descriptor of
the IPC connection to i3. Therefore, even if i3bar exits with SIGSEGV,
the connection to i3 stays open. Because nobody actually reads any
messages by i3, the buffer will fill up and i3 can’t deliver any more
messages, and thus busy-loops at that point.
fixes#995
Use the following command to reproduce this bug:
echo 4096 | sudo tee /proc/sys/net/core/wmem_default
Then just switch workspaces with some windows on it and i3bar would
exit due to malformed IPC messages.
This bug hits OpenBSD users (and possibly other BSDs) due to their lower
default buffer size.
fixes#896
While this is a bit ugly, it makes the log messages end up where they
are supposed to: in the shmlog/stdout in case of i3 and on stdout in
case of utilities such as i3-input
CPPFLGES, CFLAGS and LDFLAGS should be user variables
We now provide default flags but use I3_*FLAGS flags for our own needed
flags
Also reoder lib flags a bit
See also:
http://article.gmane.org/gmane.linux.kernel/1268792
The C compiler will handle (void) as "no arguments" and () as "variadic
function" (equivalent to (...)) which might lead to subtle errors, such
as the one which was fixed with commit 0ea64ae4.
You need to specify the --enable-32bit-visual flag when starting i3. This is
done because everything feels sluggish on my system when using a 32 bit visual
instead of a 24 bit visual. Fast > fancy.
After a reload, the drawing parameters for the decorations might
have changed, so we need to invalidate the cache and force a redraw
of the currently visible decorations. Also, don't leak the previous
font when reloading by freeing it before parsing the config.
Abstracted draw_text and predict_text_width into libi3. Use
predict_text_width from libi3 in i3 too. This required tracking
xcb_connection in a xcb_connection_t *conn variable that libi3
expects to be available in i3bar.
Also, the API changed a bit. There are two functions now, both assume you
already got the keysyms (which is the case for i3 and i3-config-wizard),
one gets the modifier mapping for you (aio_get_mod_mask_for) while the other
assumes you also got that. No roundtrips are required for the latter.
Michael Stapelberg