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.
This change has two implications:
1) tree_render() will now be called precisely once for input which consists of
multiple commands (like "focus left; focus right"). Also, the caller of
parse_command() has to call it. This makes us able to fix tickets such as
ticket #608 (where multiple tree_render() calls are noticable).
2) The output of a command is now a JSON array of return values of the
individual subcommands. In the case of "focus left; focus right", this is:
[{"success":true}, {"success":true}]
While this is incompatible with what i3 returned before, the return value of
commands was undocumented and therefore not subject to our API stability.
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.
Fixes floating containers seemingly showing up in the wrong
workspace after moving workspaces containing floating containers.
We must *always* fix the coordinates of floating containers when
moving workspaces across outputs. That's because the coordinates
of floating containers are *not* relative to the workspaces.
Currently it supports the following options:
"oldest": match the first window that triggered an urgent event
"latest": match the last window that triggered an urgent event
This behavior can be avoided by passing dont_create_temp_dir => 1 to
launch_with_config (or activate_i3).
This commit fixes t/159-socketpaths.t being flaky on non-systemd computers.
If you had workspace 1, 2, 3, 4 on LVDS1 and you enabled HDMI2 (where workspace
1 to workspace 5 are assigned to HDMI2), i3 would look for a new workspace for
LVDS1 (since all workspaces were moved), create workspace 5, move that over due
to assignment and then create workspace 6. Effectively, you would end up with
an empty workspace 5.
We now use 5px padding for the workspace text on both sides. Some
fonts will look off-by-one (e.g. fixed), but that's because X core
fonts have padding. This padding is per-char, varies wildly across
different fonts, and would be a major pain to offset for. Even if
we could take this padding into account, this would probably make
things look even worse for some fonts.
Michael Stapelberg