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.
We now wait for the child process to send the first line before stopping
it to use the signal which might be specified in the i3bar protocol
header
Since clients might use the same signal for both stop and cont, we also
save the stopped state of the child to avoid stopping it while hidden!
While this is a bit ugly, it makes the log messages end up where they
are supposed to: in the shmlog/stdout in case of i3 and on stdout in
case of utilities such as i3-input
When a workspace marked 'urgent', i3bar unhide
itself. if I want to hide it again, I must press the
modifier.This sometimes annoys me.
In this patch I change the above behavior to this:
If a urgent workspace occurs, i3bar will unhide itself;
and when you navigates away from the last urgent
workspace and there is no more urgent workspace, i3bar
will hide itself.
yajl1 has the status yajl_status_insufficient_data, which in our stream
parsing context basically means "ok". Therefore, in yajl1, we no longer
print an error in this case.
This can happen if you move your mouse pointer to the very left of the
screen and then click. For better usability, we handle this edge case
like a click on pixel 0.
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.
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.
This re-introduces borders around the workspace buttons in i3bar.
No additional pixels will be consumed (you will not lose any space for your
windows).
Abstracted draw_text and predict_text_width into libi3. Use
predict_text_width from libi3 in i3 too. This required tracking
xcb_connection in a xcb_connection_t *conn variable that libi3
expects to be available in i3bar.
i3bar previously used get_colorpixel on strings without the leading # (ff0000
instead of #ff0000). Since it uses libi3’s get_colorpixel now we needed to
update a few places.
The new default looks like this (like in docs/userguide):
colors {
background #000000
statusline #ffffff
focused_workspace #ffffff #285577
active_workspace #888888#222222
inactive_workspace #888888#222222
urgent_workspace #ffffff #900000
}
If you want to go back to the previous colors, use:
colors {
background #000000
statusline #ffffff
focused_workspace #ffffff #480000
active_workspace #ffffff #480000
inactive_workspace #ffffff #240000
urgent_workspace #ffffff #002400
}
In order to not duplicate configuration options and make stuff confusing, we
dropped the commandline flags (except for socket_path and bar_id). This means
that you *have to* specify bar_id when starting i3bar. The best way is to let
i3 start i3bar, which it will do automatically for every bar {} configuration
block it finds.
Thanks to yvesf for this simple python test script:
from gi.repository import Gtk as gtk
def cb(*a):
print a
def si_popup(*a):
print a
status_icon = gtk.StatusIcon()
status_icon.set_from_stock(gtk.STOCK_OPEN)
status_icon.connect("activate", cb)
gtk.main()
This fixes the condition where the i3 socket for some reason did not produce an
error, but the X server exited (earlier than i3?) and the left-over i3bar
process would consume 100% CPU.
How to reproduce the problem:
1) Start ./testcases/Xdummy :8
2) Start DISPLAY=:8 i3bar -s <socket path to i3 on :0>
3) Kill the Xdummy
In case of a 1024 px screen and a 1128 px status line, the status line was not
only cut off (it has to be, obviously), but the right part showed some black
pixels.
Michael Stapelberg
