If the user clicks on the very top of i3bar above a tray icon, i3bar might
mistakenly trigger the click event for the last status block. This is due to
the fact that the click detection considers the separator width of the block
even though on the last block this is ignored, incorrectly spanning the block's
width partially (or entirely) across the tray area.
The Makefiles should put binaries in $(EXEC_PREFIX) and
architecture-independent files in $(PREFIX). Also a user may have a
prefixed- pkg-config, as in the case of cross compiling on Exherbo
Linux, so respect the well-accepted $(PKG_CONFIG) variable for this
purpose.
1. Add a function writeall and make swrite wrap that function. Use either writeall or swrite, depending on whether we want to exit on errors or not.
2. Fix warnings when compiling with a higher optimisation level.
(CFLAGS ?= -pipe -O3 -march=native -mtune=native -freorder-blocks-and-partition)
Signed-off-by: hwangcc <hwangcc@csie.nctu.edu.tw>
This introduces a "separator_symbol" property for the i3bar configuration.
If set, the specified string will be used as a separator instead of a vertical line. Since it is an optional configuration, complete backwards compatibility is given.
fixes#1472
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 combines detecting of current and clicked workspaces into one cycle
and then checks if the x coordinate of the clicked point is greater than
the workspace buttons width.
This draws the statusline after drawing (and calculating width of) the
workspace buttons and fixes calculation of its maximum visible width.
This (hopefully) guarantees that these two will never overlap.
This fixes the bug when statusline pixmap wasn't entirely cleared that
caused random artifacts to appear when the statusline width is greater
than the screen width.
Not quite sure why there are so many differences. Perhaps we’ve gotten
out of the habit of running clang-format after every change.
I guess it’d be best to have a travis hook that runs clang-format for us
and reports any problems on pull requests.
Michael Stapelberg