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.
A buffer is introduced for the statusline which will only be copied to the actual statusline
once an entire statusline is parsed. This avoids a race condition where incompletely parsed
statuslines were rendered, causing only some status blocks to be rendered which is visible to
the user as a flickering.
fixes#1480
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
1. Always subscribe to click events for i3bar.
2. Exit the click event handler if no current workspace was found only after clicks on status blocks have been handled.
fixes#1430
Dynamically update the font when the `reload` command is called by
reloading the font with `xcb_init_late` and adjusting the size of the
bar by updating the output dimensions with a call to the ipc.
Without this call, sometimes the tray icon windows are reparented into
i3’s container around the i3bar window, i.e. into the next remaining
window in the window hierarchy. Since i3 then closes that container
(since the i3bar window itself was closed), the tray window will also
get closed. In general, this weird interaction (getting reparented and
then closed) is not well received by tray icon providers :).
closes: #1296
Users can specify a command to run when a button was pressed on i3bar to
override the default behavior. Currently only the mouse wheel buttons
are supported. This is useful for disabling the scroll wheel action or
running scripts that implement custom behavior for these buttons.
Example:
bar {
wheel_up_cmd nop
wheel_down_cmd exec ~/.i3/scripts/custom_wheel_down
}
fixes#1104
This removes our last dependency on Xlib! :)
(Okay, an Xlib dependency still comes in through other libraries that we
link against, but it’s not us. Our code is simpler by this change and
uses one less connection to X11.)
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 has multiple effects:
1) The i3 codebase is now consistently formatted. clang-format uncovered
plenty of places where inconsistent code made it into our code base.
2) When writing code, you don’t need to think or worry about our coding
style. Write it in yours, then run clang-format-3.5
3) When submitting patches, we don’t need to argue about coding style.
The basic idea is that we don’t want to care about _how_ we write the
code, but _what_ it does :). The coding style that we use is defined in
the .clang-format config file and is based on the google style, but
adapted in such a way that the number of modifications to the i3 code
base is minimal.
Implement the configuration option within the bar config directive for
custom workspace numbers with the directive `strip_workspace_numbers
yes`.
This directive strips the workspace name of the number prefix and
delimiter. When the workspace name consists only of the number, it will
default to show the number.
For example:
* "2:5" -> "5"
* "4:$" -> "$"
* "8" -> "8"
This allows customization of i3bar for alternate ordering of workspaces
which has a legitimate use for alternate keyboard layouts such as
Dvorak.
fixes#1131
Do not handle click events on dock clients because they are not managed
windows. Dock clients are responsible for sending the message to i3 to
focus a workspace if that is appropriate. i3bar now sends the message to
focus the correct workspace when that is appropriate.
Otherwise, it could interfere with the dock clients own click handling,
which could be an action to focus a different workspace than i3 had
assumed, such as would be the case with a workspace widget.
Wait for the child process to exit on its own before freeing
watcher-related resources.
i3bar shows the last received status line until the process exits.
Fixes a race condition where the termination signal was sometimes not
received to display a meaningful error message.
When the `status_command` sends EOF, it is terminated. Terminating this
process prints an error message to the status line (hence, a race
condition). This error message is always more useful than the former
"EOF" status line error because it shows the exit code.
Exit 127 can be returned by the shell when the command is not found or
when the `status_command` process returns 127 because of a missing C
library dependency.
If a command is passed to `start_child` which is NULL, such as in the
case when there is no `status_command` specified in the bar config, do
not start a child process to listen on stdin.
fixes#1140
When a trayclient is first created as a structure in memory, explicitly
set the `mapped` flag to false. Otherwise it may initialize to `true` in
some circumstances without actually being mapped, causing a request to
be mapped from the client to be ignored.
Create the trayclient in memory before handling a request to be mapped
immediately.
fixes#1138
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
Add a function to i3bar to print an error message in the status line
when the child process invoked by status_command fails to provide
input that can be displayed as a statusline.
When the child provides JSON that cannot be parsed, alert the user and
convey a short message provided by yajl communicating the specific
problem.
When the child (or the shell executing the status command) exits
unexpectedly, alert the user and display the exit code. The cases where
the status command is not executable or not found in the user's PATH are
treated specially.
fixes#1130
Set the process group id of the child process by calling `setpgid` after
forking and before calling `exec`.
The process group ID will be set to the process ID of the forked
process. Processes spawned by this child process will also have this
group ID.
Send signals to the process group with `killpg`. This will send the
signal to all of the process group.
fixes#1128
UnmapNotify events are interpreted by i3bar as an action taken by an
application to hide its tray window. Likewise, MapNotify events are
interpreted as an action taken by by an application to show its tray
window.
The actual cause of these events may be the application itself, or the
result of some action taken by i3bar itself at the request of the
application in the course of the XEmbed protocol.
We respond by adjusting the size of the tray window and realigning any
tray clients that remain. This will make room for the mapping window or
close the gap left by the unmapping window when the bar is redrawn.
fixes#1110
Handle DestroyNotify events by removing the tray client from the tray
client list held in memory.
This change is intended to be part of the i3bar's implementation of the
XEmbed protocol. For more information, see:
<http://standards.freedesktop.org/xembed-spec/xembed-spec-latest.html>
According to the XEmbed protocol specification, this is one way for a
tray client to finish the protocol. After this event is received, i3bar
should have no more interaction with the tray client.
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.
When determining whether to hide or unhide the bar on redraw in hide
mode, use simpler rules. When the config specifies the 'show' state or a
workspace is urgent, or if the caller requests it, or the modifier is
pressed, show the bar. Otherwise, hide the bar.
Michael Hofmann