The possible values "rename", "reload" and "restored" of the property
'change' from the workspace event were missing. Because no events of
those types contain an old workspace, this was trivial.
This event is triggered when the connection to the ipc is about to
shutdown because of a user action such as with a `restart` or `exit`
command. The `change` field indicates why the ipc is shutting down. It
can be either "restart" or "exit".
fixes#2318
This commit probably comes as a surprise to some, given that one of i3’s
explicitly stated goals used to be “Do not use programs such as
autoconf/automake for configuration and creating unreadable/broken makefiles”.
I phrased this goal over 7 years ago, based largely on a grudge that I
inherited, which — as I’ve realized in the meantime — was largely held against
FOSS in general, and not actually nuanced criticism of autotools.
In the meantime, I have come to realize that the knee-jerk reaction of “I could
do this better!” (i.e. writing our own build system in this particular case) is
usually misguided, and nowadays I strongly suggest trying hard to fix the
existing system for the benefit of all existing and future users.
Further, I recently got to experience the other side of the coin, as I packaged
a new version of FreeRADIUS for Debian, which at the time of writing used
autoconf in combination with boilermake, a custom make-based build system that
only FreeRADIUS uses. Understanding the build system enough to fix issues and
enable parallel compilation took me an entire day. That time is time which
potentially every downstream maintainer needs to invest, and the resulting
knowledge cannot be applied to any other project.
Hence, I believe it’s a good idea switch i3 to autotools. Yes, it might be that
particular features were easier to implement/understand in our custom
Makefiles, and there might be individuals who have an easier time reading
through our custom Makefiles than learning autotools. All of these
considerations are outweighed by the benefits we get from using the same build
system as literally thousands of other FOSS software packages.
Aside from these somewhat philosophical considerations, there’s also practical
improvements which this change brings us. See the “changes” section below.
┌──────────────────────────────────────────────────────────────────────────────┐
│ new workflow │
└──────────────────────────────────────────────────────────────────────────────┘
You can now build i3 like you build any other software package which uses
autotools. Here’s a memory refresher:
autoreconf -fi
mkdir -p build && cd build
../configure
make -j8
(The autoreconf -fi step is unnecessary if you are building from a release
tarball, but shouldn’t hurt either.)
┌──────────────────────────────────────────────────────────────────────────────┐
│ recommended reading │
└──────────────────────────────────────────────────────────────────────────────┘
I very much recommend reading “A Practitioner's Guide to GNU Autoconf,
Automake, and Libtool” by John Calcote (https://www.nostarch.com/autotools.htm).
That book is from 2010 and, AFAICT, is the most up to date comprehensive
description of autotools. Do not read older documentation. In particular, if a
document you’re reading mentions configure.in (deprecated filename) or
recursive make (now considered harmful), it’s likely outdated.
┌──────────────────────────────────────────────────────────────────────────────┐
│ changes │
└──────────────────────────────────────────────────────────────────────────────┘
This commit implements the following new functionality/changes in behavior:
• We use the AX_ENABLE_BUILDDIR macro to enforce builds happening in a separate
directory. This is a prerequisite for the AX_EXTEND_SRCDIR macro and building
in a separate directory is common practice anyway. In case this causes any
trouble when packaging i3 for your distribution, please let me know.
• “make check” runs the i3 testsuite.
You can still use ./testcases/complete-run.pl to get the interactive progress
output.
• “make distcheck” (runs testsuite on “make dist” result, tiny bit quicker
feedback cycle than waiting for the travis build to catch the issue).
• “make uninstall” (occasionally requested by users who compile from source)
• “make” will build manpages/docs by default if the tools are installed.
Conversely, manpages/docs are not tried to be built for users who don’t want
to install all these dependencies to get started hacking on i3.
• non-release builds will enable address sanitizer by default. Use the
--disable-sanitizers configure option to turn off all sanitizers, and see
--help for available sanitizers.
• Support for pre-compiled headers (PCH) has been dropped for now in the
interest of simplicitly. Maybe we can re-add it later.
• coverage reports are now generated using “make check-code-coverage”, which
requires specifying --enable-code-coverage when calling configure.
┌──────────────────────────────────────────────────────────────────────────────┐
│ build system feature parity/testing │
└──────────────────────────────────────────────────────────────────────────────┘
In addition to what’s described above, I tested the following features:
• “make install” installs the same files (plus documentation and manpages)
cd i3-old && make install PREFIX=/tmp/inst/old
cd i3-new && ./configure --prefix=/tmp/inst/new
cd /tmp/inst
(cd old && for f in $(find); do [ -e "../new/$f" ] || echo "$f missing"; done)
• make dist generates a tarball which includes the same files
cd i3-old && make dist
cd i3-new/x86_64-pc-linux-gnu && make dist
colordiff -u <(tar tf i3-old/i3-4.12.tar.bz2 | sort) \
<(tar tf i3-new/x86_64-pc-linux-gnu/i3-4.12.tar.gz | sort)
There are some expected differences:
• Some files have been renamed (e.g. the new etc/ and share/ subdirectories)
• Some files will now be generated at build-time, so only their corresponding
.in file is shipped (e.g. testcases/complete-run.pl)
• The generated parser files are shipped in the dist tarball (they only
depend on the parser-specs/* files, not on the target system)
• autotools infrastructure is shipped (e.g. “configure”, “missing”, etc.)
• DLOG and ELOG statements still produce the same file name in logfiles
• Listing source code in gdb still works.
• gdb backtraces contain the i3-<version> path component
• release.sh still works
• version embedding
1. git checkout shows “4.12-136-gf720023 (2016-10-10, branch "autotools")”
2. tarball of a git version shows “4.12-non-git”
3. release tarball shows 4.13
• debug mode is enabled by default for non-release builds
• enabling verbose builds via V=1
┌──────────────────────────────────────────────────────────────────────────────┐
│ speed │
└──────────────────────────────────────────────────────────────────────────────┘
There is no noticeable difference in compilation speed itself (of binaries,
documentation and manpages):
i3-old $ time make all docs mans -j8
make all docs mans -j8 28.92s user 2.15s system 640% cpu 4.852 total
i3-new $ time make -j8
make -j8 27.08s user 1.92s system 620% cpu 4.669 total
In terms of one-time costs:
configuring the build system (../configure) takes about 2.7s on my machine,
generating the build system (autoreconf -fi) takes about 3.1s on my machine.
┌──────────────────────────────────────────────────────────────────────────────┐
│ m4 macros │
└──────────────────────────────────────────────────────────────────────────────┘
All files in m4/ have been copied from the autoconf-archive package in version
b6aeb1988f4b6c78bf39d97b6c4f6e1d594d59b9 and should be updated whenever they
change.
This commit has been tested with autoconf 2.69 and automake 1.15.
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
This patch moves the title_format information from windows to containers.
Furthermore, it allows correctly setting it on window-less containers and
displays the title accordingly for split containers.
We now also dump and read title_format in GET_TREE / during restarts.
fixes#2120
This commit fixes#1969 by adding support for matching a window's type
against _NET_WM_WINDOW_TYPE_NOTIFICATION. The userguide and tests were
updated to reflect this change.
This patch introduces the possibility to specify the tray_output directive
multiple times. All values will be used by i3bar, in the order they are
given.
This way, a single bar configuration can be used for several machines with
internal output names "eDP1" and "LVDS-0" by specifying tray_output for both.
Any external output (e.g., "DP-0") will still not receive the tray. The same
effect can be achieved by using "primary", but forces the user to couple the
tray display to the primary output which may not be desirable behavior.
relates to #555
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
This patch adds two new status block keys, background and border, which
define the respective colors for the status block. If not specified, the
current behavior is kept, e.g., no background / border will be drawn.
If the status block is marked urgent, the urgent color is prioritized.
fixes#2022
This allows matching with
[con_id=__focused__] unmark
for commands that do not default to operating on the focused window
if no criteria have been specified (such as unmark).
relates to #2014
This patch allows using 'unmark' on matched windows. The old behavior
of applying it to all windows if no criteria were specified is kept.
relates to #2014
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 patch allows multiple marks to be set on a single window. The restriction that a mark may
only be on one window at a time is still upheld as this is necessary for commands like
"move window to mark" to make sense.
relates to #2014
- Render key names and key bindings verbatim if they could be used like
that in the configuration (no special format for "colloquial" names:
Alt, Windows, ...)
- Use only lower case letters for key bindings
In some cases the IDs of section titles was placed after the section
title. With that in the rendered HTML the ID was placed on the paragraph
and not on the heading. This led to heading not being shown when the
corresponding link was clicked.
The headline indicated that it would be possible to move containers and *workspaces* to marks but the following text clearly shows that it should state containers and *windows*.
See the issue #1798 (http://github.com/i3/i3/issues/1798).
+workspace_next+ as-is cycles through either numbered or named workspaces,
but when it reaches the last numbered/named workspace, it only looks for
named workspaces. This commit changes it: look for named workspaces after
exhausting numbered ones, but also for numbered ones after exhausting
named ones.
Also add a test case 528-workspace-next-prev.t (numbered workspaces and named
workspaces on 2 outputs) for testing this.
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
With this patch, the no_focus directive will be ignored if the
to-be-opened window is the first on its workspace as there's no
reason the user would not want to focus it in this case.
This improves usability when, for example, using a tabbed
workspace_layout.
fixes#1987
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.
1. Allow to use the line continuation, which is indicated by \ before the new line character, in config files.
2. Add a new testcase "247-config-line-continuation.t" for
a). testing line continuation
b). making sure string escaping still works
c). testing line continuations within a string
b). testing line continuations with too many lines
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
Stefan Hagen