Receiving EOF from a client is not an error, but rather a standard way a
client may disconnect from the IPC. This should rather be logged from
a consumer of the libi3 ipc_recv_message() function as a normal client
disconnect event.
fixes#1252
This avoids flooding stdout every time some text (e.g. a window
decoration) is drawn, yet leaves the message in place when it’s actually
relevant (upon DPI changes).
fixes#1115
Since the macro PATH_MAX is not defined on every system (GNU/Hurd being
one of those who do not define it), we remove all references to this
macro. Instead, we use a buffer of arbitraty size and grow it when
needed to contain paths.
This removes code duplication, which will be useful for a subsequent
commit.
Furthermore, we now don’t open X11 connections unnecessarily in some
corner cases.
The pango font specification accepts a font size in points, but pango
defaults to a DPI of 96. Create a default PangoContext (which
internally creates a default PangoCairoFontMap as usual) and set the
DPI to the value of the root Screen manually.
Fixes#1115
When drawing a text with Pango, shift it to the top according to the top
if the glyph if taller than expected
We always shift of (height - savedHeight) which is a no-op for normal glyphs
Signed-off-by: Quentin Glidic <sardemff7+git@sardemff7.net>
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.
Tony Crisci