Add `markup` to the i3bar protocol as a block member.
This is a string that determines how the block should be parsed as
markup. "pango" indicates the block should be parsed as Pango markup.
"none" indicates the block should not be parsed as markup.
Parse text within workspace buttons and the i3bar statusline as Pango
markup. This lets people specify things like font weight, text color,
background color, font size, and font family in the text of i3bar.
fixes#1468
When loading a new font with `load_font`, free the previously loaded
font with `free_font`.
If no font is loaded, `free_font` will simply return (instead of
crashing because of a double free).
This should be the last commit that formats a big bunch of files. From
here on, whenever I merge patches, I’ll run clang-format like described
in the title.
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.
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
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.
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