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]
This commit should fix problems with people using a non-bourne shell as
login shell, e.g. fish or rc. AFAICT, $SHELL should only be used for
interactive shells, but we just want a bourne shell, not an interactive
shell.
If the config specifies a `tray_output` not in the list of outputs over
which this bar will span, do not initialize a tray for the bar.
Fixes former behavior, which was to initialize the tray without showing
the icons, causing disapearing tray icons in multi-monitor environments
when `tray_output` isnt `output`.
i3 current behavior hides the binding mode indicator when
workspace buttons are disabled.
This patch adds a new configuration for i3bar called
'binding_mode_indicator' which acts like the workspace_buttons.
It is now possible to configure i3bar to hide the
workspace buttons and keep showing the binding mode indicator.
This should make the hide workspace buttons configuration
more convenient for those who are heavily using binding
modes.
Default value for binding_mode_indicator is true.
This makes the workspace buttons align with the window borders, which is
particularly visible with color configurations like the one in this
screenshot: http://i.imgur.com/CH8srF5.pngfixes#687
When connecting or disconnecting an output, i3bar reconfigures its
windows. This also included an unmapping of the bars, and a remapping of
all docked bars. Thus, the bars were misplaced when a monitor was
disconnected.
This commit assures that the remapping of the bars only takes place,
when the mode has actually changed. This patch also takes care of an
inconsistency when pressing the bar_modifier while switching the mode.
Also, the xkbDisplay is now closed correctly, when deregestering the xkb
keyevents.
The hidden_state and mode of each i3bar instance can now be controlled from within i3.
Therefore, two new i3 command were introduced:
_
bar hidden_state show|hide|toggle [<bar_id>]
show: always show the bar
hide: normal hide mode
toggle: toggle between show and hide (individually for each bar)
_
bar mode dock|hide|invisible|toggle [<bar_id>]
hide,dock: like before
invisible: always keep the bar hidden
toggle: toggle between dock and hide (individually for each bar)
This patch introduces a hidden_state ("hidden_state hide|show") in the
barconfig, which indicates the current hidden_state of each i3bar
instance. It only affects the bar when in hide mode. Additionally, a new
invisible mode was introduced. In order to change the hidden_state or
mode of the bar from i3, a barconfig-update event was introduced, for
which a bar can subscribe and the bar then gets notified about the
currently set hidden_state and mode in its barconfig.
For convenience, an id field ("id <bar_id>") was added to the barconfig, where one can
set the desired id for the corresponding bar. If the id is not specified, i3 will
deterministically choose an id; otherwise, with the previous random approach for finding
a new id, which is actually not shared with i3bar, as it would determine its id on
startup, the event-subscription would be destroyed on reload. Still, this issue remains
when manually changing the bar_id in the config and then reloading.
fixes#833, #651
When running i3bar on a dual-head display with workspaces enabled in i3bar's
config, the second monitor wouldn't use a correct x position offset and
would draw its label too close to the screen's edge. In comparison to the
first monitor, this is inconsistent because that starts with a pixel offset
of 1.
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.
Set the colors in the GC directly since set_font_colors() does not do it
when using a Pango font, resulting in i3bar drawing separators in the
wrong color.
With this change, min_width can either be an integer (as usual), or a
string. In the latter case, the width of the text given by min_width
determines the minimum width of the block. This way one does not have to
figure out a minimum width by trial and error, only to do it again every
time the font is changed.
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.
Tony Crisci
