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
Tony Crisci
