Use case:
* When managing multiple terminals in a workspace, the borders makes it easier
to know where the focus is, but when there is only one it's obvious where the
focus is.
* When there's only a web browser for example, the borders are actually counter-
productive since it makes clicking a side scrollbar or a tab a bit harder (if I
smash my cursor to the side or the top of the workspace, I have to move it in
the other direction by just a few pixels to be able to grab it)
Behaviour:
* No borders when there's a single window in a workspace
* Borders when there are multiple windows in a workspace
fixes#2188
This patch introduces a new 'set_from_resource' config directive which
allows defining a variable by retrieving its value from the X resource
database. This avoids having to configure a color scheme in multiple
files. The directive takes an additional fallback value which is used
in case the resource cannot be found or during config validation where
no X connection is available.
Furthermore, this patch includes the following changes:
- If the same variable is defined twice, we now properly overwrite the
value of the assignment rather than inserting two variable definitions
with the same key.
- We now depend on xcb-util-xrm to query the resource.
- Increase the buffer size for variable / resource assignments.
fixes#2130
This allows "modifier none" (and "modifier off") for the bar config
in order to disable the modifier key altogether. This is useful
for users who use a different approach to hiding / showing the bar,
e.g., a custom keybind that involved multiple keys or scripts.
fixes#2208
Until now, only the config directive for borders (new_window,
new_float) respected the DPI setting (using logical_px). This
patch makes sure we also do so for runtime "border" commands.
fixes#2202
According to the User's Guide [1], an `assign` command allows a
`workspace` token after the selector, as an alternative or in addition
to the unicode arrow `→`. In reality, however, the `workspace` token is
not recognized.
Example:
assign [class="Firefox"] workspace "1: Browser"
should assign Firefox windows to workspace `1: Browser`, but the the
browser window appears on a new workspace called
`workspace "1: Browser"` instead.
With this fix, both `→` and `workspace` are recognized (and ignored)
after the selector.
[1] https://i3wm.org/docs/userguide.html#_automatically_putting_clients_on_specific_workspaces
This patch extends the previously introduced flag --no-auto-back-and-forth
to also apply to
move window to workspace <name>
move window to workspace number <number>
relates to #2028
This patch introduces the --no-auto-back-and-forth flag to both of
workspace --no-auto-back-and-forth <name>
workspace --no-auto-back-and-forth number <number>
This flag will only have an effect if the back_and_forth feature is
enabled. If passed, the feature will be ignored for this particular
call only.
fixes#2028
In order to keep compatibility to before allowing multiple marks on a window,
we introduce a flag "--add" that must be set to put more than one mark on a
window. The default, which is also available as "--replace", keeps the old
behavior of overwriting a mark when setting a new one.
fixes#2014
This introduces the flag "--pango" on the mode config directive to
explicitly enable pango markup for mode names. Not setting this will
cause the mode name to be rendered as is.
This fixes a regression in 4.11 where mode names containing characters
such as '<' would break user's configs as they didn't escape these
characters.
fixes#1992
fixes#1835
This commit improves the translation of keysyms to keycodes by loading
keymaps using libxkbcommon-x11 and using libxkbcommon for figuring out
the keymap, depending on each keybinding’s modifiers. This way, the
upper layers of complex layouts are now usable with i3’s bindsym
directive, such as de_neo’s layer 3 and higher.
Furthermore, the commit generalizes the handling of different XKB
groups. We formerly had support only for two separate groups, the
default group 1, and group 2. While Mode_switch is only one way to
switch to group 2, we called the binding option Mode_switch. With this
commit, the new names Group1, Group2 (an alias for Mode_switch), Group3
and Group4 are introduced for configuring bindings. This is only useful
for advanced keyboard layouts, such as people loading two keyboard
layouts and switching between them (us, ru seems to be a popular
combination).
When grabbing keys, one can only specify the modifier mask, but not an
XKB state mask (or value), so we still dynamically unbind and re-bind
keys whenever the XKB group changes.
The commit was manually tested using the following i3 config:
bindsym Group4+n nop heya from group 4
bindsym Group3+n nop heya from group 3
bindsym Group2+n nop heya from group 2
bindsym n nop heya
bindsym shift+N nop explicit shift binding
bindsym shift+r nop implicit shift binding
bindcode Group2+38 nop fallback overwritten in group 2 only
bindcode 38 nop fallback
…with the following layout:
setxkbmap -layout "us,ua,ru,de" -variant ",winkeys,,neo" \
-option "grp:shift_caps_toggle,grp_led:scroll" \
-model pc104 -rules evdev
By default (xkb group 1, us layout), pressing “n” will result in the
“heya” message appearing. Pressing “a” will result in the “fallback”
message appearing. “j” is not triggered.
By pressing Shift+CapsLock you switch to the next group (xkb group 2, ua
layout). Pressing “a” will result in the “fallback overwritten in group
2 only” message, pressing “n” will still result in “heya”. “j” is not
triggered.
In the next group (xkb group 3, ru layout), pressing “a” will result in
the “fallback” message again, pressing “n” will result in “heya”,
“j” is not triggered.
In the last group (xkb group 4, de_neo layout), pressing “a” will still
result in “fallback”, pressing “n” will result in “heya”, pressing “j”
will result in “heya from group 4”.
Pressing shift+n results in “explicit shift binding”, pressing shift+r
results in “implicit shift binding”. This ensures that keysym
translation falls back to looking at non-shift keys (“r” can be used
instead of ”R”) and that the order of keybindings doesn’t play a role
(“bindsym n” does not override “bindsym shift+n”, even though it’s
specified earlier in the config).
The fallback behavior ensures use-cases such as ticket #1775 are still
covered.
Only binding keys when the X server is in the corresponding XKB group
ensures use-cases such as ticket #585 are still covered.
If the match expression is a plain number (e.g., '99'), the number of a workspace will be compared strictly. Otherwise, the match expression is taken as a regular expression and compared against the workspace's name.
This allows all of the following:
for_window [workspace=5] ...
for_window [workspace="5:foo"] ...
for_window [workspace="foo"] ...
fixes#1769
* <xyz> denotes that some string must be used which is not a fixed value (e.g., a command), but a variable string (text, a number, ...)
* [xyz] denotes that the parameter is optional
* abc|xyz denotes that either abc or xyz must be given
* Implement criterion specs just like it is done in the spec for the config
* Declare variables in test case early so the 'my' keyword can be dropped in the actual test cases
Outputs may disappear momentarily and come back later.
To prevent i3 from exit when no output is available momentarily, add a timeout delay_exit_on_zero_displays.
Introduce a config directive "show_marks [yes|no]" to en- or disable drawing marks on window decorations.
To not change the look & feel of existing configurations, the default is "no".
When a window receives a _NET_ACTIVE_WINDOW message, it can steal the focus. This may not be preferable to all users.
With this directive, the user can choose from one of the following:
1) 'smart' - focus the container if its workspace is visible, otherwise set the urgency flag (default)
2) 'urgent' - always set the urgency flag, do not steal focus
3) 'focus' - always switch focus, never set the urgency hint
4) 'none' - ignore the request entirely (do not switch focus, nor set the urgency hint)
fixes#1426
This option allows toggling marks on a window without knowing whether the mark is already set or not.
It behaves as follows:
1) If the matched window has no mark, the new mark is set.
2) If the matched window has another mark, the old mark is removed and the new mark is set.
3) If the matched window already has the mark, the mark is removed.
The behavior that all non-matched windows have this mark removed is kept.
fixes#1463
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
Ingo Bürk