This change introduces support for four new properties on the i3bar
protocol, namely "border_top", "border_right", "border_bottom"
and "border_left".
If a block is drawn with a border, these values define the width of
the corresponding edge in pixels. They all default to 1 if not
specified to preserve compatibility.
fixes#3722
https://llvm.org/bugs/show_bug.cgi?id=30353 was filed for the unintended
line break between in e.g. “TAILQ_ENTRY(foo)\nbar;”.
Until that’s fixed or a workaround is known, we’ll live with line
breaks. To make it a bit easier for readers to see what’s going on, I
added extra line breaks around each such struct member/variable
definition, so that they at least visually are a single unit.
fixes#2174
Including config.h is necessary to get e.g. the _GNU_SOURCE define and
any other definitions that autoconf declares. Hence, config.h needs to
be included as the first header in each file.
This is done either via:
1. Including "common.h" (i3bar)
2. Including "libi3.h"
3. Including "all.h" (i3)
4. Including <config.h> directly
Also remove now-unused I3__FILE__, add copyright/license statement
where missing and switch include/all.h to #pragma once.
In order to prepare for using cairo for rendering i3 decorations,
we need to make the draw_util.c from i3bar available via libi3 such
that both i3bar and i3 can use it.
relates to #1278
This patch adds two new status block keys, background and border, which
define the respective colors for the status block. If not specified, the
current behavior is kept, e.g., no background / border will be drawn.
If the status block is marked urgent, the urgent color is prioritized.
fixes#2022
This commit restores the old XCB drawing code paths while keeping the
cairo drawing available via a compile-time switch (I3BAR_CAIRO). This
is necessary as cairo currently has a bug that breaks i3bar for users
without the RENDER extension, which might be the case, e.g., for VNC
users.
For more context, see #1989 and the discussions about its fix. Once the
cairo fix is available in a stable release, i3 can depend on that version
and remove the XCB drawing code paths.
fixes#1989
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.
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.
If the statusline generator (i.e. i3status) specifies click_events:true
in the protocol header, i3bar will write a JSON array on it's stdin
notifying it if the user clicks on a block.
The exact protocol is documented in docs/i3bar-protocol.
This patch adds the following features:
1) Configure a color of the separator via config. It is done like
bar {
colors {
separator #000000
}
}
2) A block can have an integer entry "separator_block_width" which
sets the width of the gap which would follow after the current block.
3) A block can have a boolean entry "separator" and if it is set
to false, then the drawing of the separating line would be disabled.
If the first line of the input starts with {"version":, then the input is
considered to be JSON, otherwise it is interpreted as plain text.
Only the "full_text" and "color" parts of a block are currently understood by
i3bar.
Fixes the case where multiple lines are read in a single read syscall
(it could be better optimized in the future). Also fixes a memory
corruption issue when rec == 0.
Ingo Bürk