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.
Michael Stapelberg