This allows the floating container's top left corner to be mapped
outside any output as long as they are contained partially by one. This,
for example, will allow:
mpv --geometry +1+1 video.mp4
For windows mapped to (0, 0) see comment in floating.c:270-273:
/* Some clients (like GIMP’s color picker window) get mapped
* to (0, 0), so we push them to a reasonable position
* (centered over their leader) */
The floating_reassign_ws call is removed since we try to place the new
floating container in the current output:
/* Sanity check: Are the coordinates on the appropriate output? If not, we
* need to change them */
Fixes#1341
_NET_WM_STATE_FOCUSED is set on _NET_WM_STATE to indicate that the
window is focused. It must be set when the window is newly focused and
removed once the window no longer has focus.
> _NET_WM_STATE_FOCUSED indicates whether the window's decorations are
> drawn in an active state. Clients MUST regard it as a read-only hint.
> It cannot be set at map time or changed via a _NET_WM_STATE client
> message.
For example, this is used by GTK applications to show the decoration in
an active or inactive state. This change can be tested by opening a GTK
application (like evince), focusing the window and unfocusing the
window, and observing a change in the window decorations.
Fixes#2273
For command:
move window to [absolute] position X px Y px
if the optional keyword 'absolute' is provided the end result is the
same even though it is implemented differently. Only difference is that
with absolute the floating window can move completely outside of any
output.
This commit removes the 'method' argument and only keeps the sane
implementation.
With example config:
mode "a_mode" {
bindcode 27 --release mode "default"
}
bindsym $mod+r mode "a_mode"
The first time $mod+r is pressed "a_mode" is activated like normal. When
r (bindcode 27) is pressed to exit the mode:
- On the KeyPress event the corresponding bind->release is correctly
marked as B_UPON_KEYRELEASE_IGNORE_MODS.
- On the KeyRelease event the command 'mode "default"' is executed but
bind->release is still B_UPON_KEYRELEASE_IGNORE_MODS since they are only
reset on KeyPress events.
The second time $mod+r is pressed and "a_mode" is activated and when the
r key is released the 'mode "default"' is executed even though the mods
are not matching since bind->release == B_UPON_KEYRELEASE_IGNORE_MODS.
This still doesn't catch 2 cases:
1. When the order is: press $mod -> press r -> release $mod -> release
r. Since 'r' is released without any modifiers the binding matches.
2. With:
mode "resize" {
bindsym --release r mode "default"
}
bindsym r mode "resize"
This is arguably correct: on the KeyPress event we switch to the mode and
on the KeyRelease we switch back.
Before this commit, get_binding() exited on the first match without
marking the rest --release bindings with B_UPON_KEYRELEASE_IGNORE_MODS.
Similarly, once it found a --release binding during a KeyPress event it
would stop searching for a matching key press binding.
Example config, placing the --release line first will trigger the second
problem:
# i3 config file (v4)
bindsym Super_L exec notify-send "press"
# or
# bindcode 133 exec notify-send "press"
bindsym --release Super_L exec notify-send "release"
# or
# bindcode --release 133 exec notify-send "release"
Fixes#2733
From 548d74015c50d7fae14bfb8bb1989acde5fc22ae:
> 1. press $mod, press x, release x, release $mod
> 2. press $mod, press x, release $mod, release x
case (2.) didn't work, now it should be fixed.
When we run 'reload' all the assignments are freed:
e3e09119bf/src/config.c (L99-L109)
Assignments are saved to each window after they are executed:
e3e09119bf/src/assignments.c (L41-L46)
This means that the pointers stored in window->ran_assignments are
invalid (shouldn't be dangerous currently but could lead to a segfault
if the code is modified) after a 'reload'.
Fixes:
- Issue where moving an urgent (unfocused) window resets it's urgency
hint.
- Moving an unfocused container to a new parent should not move it to
the top of the focus stack.
This deals with (admittedly somewhat misbehaving) clients which
use XSetInputFocus to take focus, but then don't properly restore
focus. This has been observed with TK apps, but also, e.g., Steam.
fixes#2722fixes#3096
From comment:
https://github.com/i3/i3/issues/2990#issuecomment-368345169
To easily reproduce:
1. Open 2 floating windows
2. Focus (with `focus_follows_mouse`) the one behind
3. Move the mouse to the other workspace
4. Move the mouse inside the previous workspace (without it even
touching a window)
The problem here is that con_fullscreen_permits_focusing() does not
check if there is a blocking fullscreen container in the workspace that
the container to be focused belongs. This makes it possible to focus a
container behind a fullscreen window if it's in an unfocused workspace.
This commit introduces a change in the 'focus' command behaviour. When
focusing a container blocked by a fullscreen container, either CF_OUTPUT
or CF_GLOBAL, the blocking container loses its fullscreen mode and the
target container is focused like normal.
This should not affect directional focus commands: left, right, up,
down, parent, child.
Fixes issue #1819.
The bug triggers when _workspace_show calls tree_close_internal and
old == old_focus. Ie, when the old workspace was empty and needs to be
closed but then is accessed as output_push_sticky_windows's argument:
Breakpoint 1, output_push_sticky_windows (to_focus=0x55555589c8a0) at ../../i3/src/output.c:102
102 con_move_to_workspace(current, visible_ws, true, false, current != to_focus->parent);
(gdb) print con_exists(to_focus)
$1 = false
The access violation can also be prevented by checking if
con_exists(old_focus) but it shouldn't be necessary: the old_focus
container can only be killed when it is an empty workspace.
With --enable-sanitizers this causes i3 to exit but with
--disable-sanitizers the access violation doesn't reliably cause a crash
and the con_move_to_workspace call continues with:
(gdb) print current != to_focus->parent
$2 = 1
Since current->type is CT_FLOATING_CON and to_focus->type is
CT_WORKSPACE, in this specific case ignore_focus would always be true.
So, in this case, passing NULL instead of old_focus to
output_push_sticky_windows doesn't change the behaviour of i3.
Fixes#3075.
Prevents a false-positive error eg with config file:
set $mod Mod4
bindsym $mod+h split h
bindsym $mod+v split v
ERROR: CONFIG: Expected one of these tokens: <end>, '#', 'set ', ...
ERROR: CONFIG: Line 8: status_command i3status
ERROR: CONFIG: Line 9: }
ERROR: CONFIG: Line 10: <BE><BE><BE><BE><BE><BE>
With this change i3 will correctly switch to the focused workspace.
This fixes bug with moving floating windows with 'move <direction>' or by dragging like _NET_CURRENT_DESKTOP not getting updated or 'workspace back_and_forth' not working.
Fixes#2921.
i3bar's handle_button is modified to also handle XCB_BUTTON_RELEASE
events. During these button release events, only custom commands are
checked to avoid sending multiple workspace ipc messages.
The way this patch is implemented will allow to assign a custom command
for both the press and release of the same button:
bar {
...
bindsym buttonX exec command1
bindsym --release buttonX exec command2
}
Fixes#3068.
Issue #3049 describes a case where terminating i3 by means of SIGTERM
causes it to leak the runtime directory and all its contents. There are
multiple issues at play: first, any cleanup handlers registered via
atexit are never invoked when a signal terminates the program (see
atexit(3)). Hence, the log SHM log cleanup performed in i3_exit is not
invoked in that case. Second, compared to the shutdown path for the
'exit' command, we do not unlink the UNIX domain socket we create,
causing it to be leaked as well. Third, a handler for SIGTERM is not
registered at all despite handle_signal claiming to be the handler for
all 'Term' signals.
This change addresses all three problems and results in a graceful exit
including cleanup to happen when we receive a signal with the default
action 'Term'. It addresses issue #3049.
Previously, we used ev_check watchers, which are executed at the beginning of an
event loop iteration.
This was problematic if one of the handlers happened to fill the XCB event
queue, e.g. by reading a reply from X11 and an event happened in the meantime.
In that situation, we would hand control to the event loop, entirely ignoring
the pending event. This would manifest itself as a 1-minute hang,
reproducible (sometimes) in the i3 testsuite.
issue #2790 describes an instance of this issue in i3bar, and we fixed that by
changing the watcher priority to run last. Handling events in xcb_prepare_cb has
the same effect, as ev_prepare watchers are run just before the event loop goes
to sleep.
The sender of the _NET_ACTIVE_WINDOW client message might know better when to
set focus than i3, as i3 does not know about unmanaged (override_redirect=1)
windows.
related to https://github.com/i3/i3lock/issues/35
stbuf.st_size is of type off_t, which the standard defines as “extended signed
integral type”¹, and for which there is no correct printf format string. Hence,
we need to cast it into a hopefully-large-enough type (ugh) and use the
corresponding format string. In our case, int64_t should do it, as config files
really shouldn’t be anywhere close to those numbers.
① http://pubs.opengroup.org/onlinepubs/007908799/xsh/systypes.h.html
This way, when changing focus between outputs, the directional focus
command will focus the focused window within the parent container that
is next in the given direction.
Previously, the next window of the given direction was focused which is
Inconsistent with changing focus inside the same output.
Fixes#1160.
Allow enabling forced focus wrapping by specifying "focus_wrapping
force" in i3's configuration. This syntax supersedes the previous
"force_focus_wrapping yes" one, which remains available for backwards
compatibility.
This fixes a crash that occurs when disabling floating for a container
while it is being moved or resized.
@Deiz describes the problem:
> It occurs because the command that disables floating runs before the
event loop. So, the window is tiled, its floating parent is destroyed,
but then a key event is handled which causes the position/size of the
now-destroyed parent to be modified.
Fixes#1627
Applied for:
1. '[...] focus' for a floating container raises it to the top.
2. Focusing a window through a focus event raises it to the top.
Fixes#2572
canonicalize_output_name allowed the "primary" special output name to
be canonicalized, thus converting it to the name of whatever output
was the primary output at the time. This caused settings
(specifically, i3bar output and tray_output settings) to be stored as
specific output names, instead of the intended special names whose
referred output may change as the system's configuration (i.e. current
primary output) changes.
Add a check to canonicalize_output_name to return the name as-is if it
is the special name "primary".
Allow appending 'P' to the fake output specification to set the
created output's "primary" flag, to allow writing test cases that
depend on the presence of a primary output.
fake_outputs_init would unconditionally increase the string read
pointer variable (walk) by one character more than the number of
characters that have been read, to skip past the character delimiting
records (a comma). However, when the input string was not terminated
by a comma, it would cause the function to read past the null
terminator instead.
Avoid this by explicitly checking for the expected delimiter.
fake_outputs_init used a sprintf invocation with a throw-away buffer
to estimate how many characters the sscanf invocation consumed. This
was unnecessary, and also potentially incorrect, as differences
between the read and formatted strings (such as leading zeros) could
lead to fake_outputs_init to lose its track.
Instead, use the %n format specifier which allows saving the number of
characters consumed by sscanf so far. %n is part of C99.
All other message types are verbs, only our first-ever message COMMAND wasn’t.
While we’re here, also change the message type dictionary into a table with
clickable links to the corresponding reply type.
Authors of downstream IPC libraries are encouraged to keep the old name around
so as to not break existing code, but mark it as deprecated.
This fixes a regression introduced in commit
4e88c10564ca5366c2578908f62ec56625a26718: when attempting to move the
single child of a container in the direction of another output, i3
would move the window to the output, despite the window not being at
the edge of its output, instead of moving it to its parent container.
The bug occurred because the check for moving containers across
outputs with non-default workspace layouts (issue #1603) did not
actually verify that the moved window lies at the edge of the
workspace, despite what its comment said.
Fixes issue #2466.
Makes "assign [<criteria>] workspace number <number>" work in the same
manner as "move to workspace number <number>" instead of assigning the
window to a workspace named "number <number>".
config.spec is modified to expect a 'number' string and an extra
argument is used in cfg_assign.
For workspaces that don't exist yet, workspace_get is used as a
fallback. This also allows the user to assign to "<number> <workspace>"
eg "2: work" and the full name will be used if workspace number 2
doesn't exist yet.
Fixes#2590.
This commit also introduces slurp() which reads a file in its entirety. Using
this function instead of doing IO in the functions in load_layout.c again and
again makes the code cleaner (fixing at least two memory leaks) and avoids
re-reading the same file 3 times.
related to #2755
Convert the output names specified in the "output" and "tray_output"
fields in bar blocks in i3's configuration to the referred output's
primary name. This allows specifying names other than the primary
output's name in the given fields without changing the IPC protocol.
In addition to the name of the monitor itself (which is still used as
the i3 output's primary name), register RandR output names associated
with the RandR monitor as alternative i3 output names.
Currently, only one name is ever added, and only the first name is
ever accessed; actually using the capability to store and access
multiple names comes in the following commits.
Currently simply returns output->name, but this will make it easier to
change how output names are stored in the following commits.
Also replace reading output->name with invocations of
output_primary_name. Code which writes output->name is unchanged. Done
using a mostly mechanical replacement of output->name to
output_primary_name(output).
The code in handle_signal() wasn't clearing the struct sigaction before passing it to sigaction().
This meant that we would block a random set of signals while executing the default handler, or jump to the uninitialized __sa_sigaction__ (instead of sa_handler).
Initialize properly as we do in setup_signal_handler().
This fixes the following issue when having an error early in the config file:
==1562==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x6220000180ff at pc 0x55c837edb1d3 bp 0x7ffee7534650 sp 0x7ffee7534648
READ of size 1 at 0x6220000180ff thread T0
#0 0x55c837edb1d2 in start_of_line ../../i3/src/config_parser.c:238
#1 0x55c837edc96f in parse_config ../../i3/src/config_parser.c:493
#2 0x55c837edf527 in parse_file ../../i3/src/config_parser.c:1091
#3 0x55c837ecf14b in parse_configuration ../../i3/src/config.c:65
#4 0x55c837ed1ef4 in load_configuration ../../i3/src/config.c:230
#5 0x55c837f0a8d0 in main ../../i3/src/main.c:539
#6 0x7fb63ae042b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
#7 0x55c837e95eb9 in _start (/home/michael/i3/build/i3+0x4beb9)
0x6220000180ff is located 1 bytes to the left of 5165-byte region [0x622000018100,0x62200001952d)
allocated by thread T0 here:
#0 0x7fb63e590cf8 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.3+0xc1cf8)
#1 0x55c837f59aa6 in smalloc ../../i3/libi3/safewrappers.c:24
#2 0x55c837edef45 in parse_file ../../i3/src/config_parser.c:1029
#3 0x55c837ecf14b in parse_configuration ../../i3/src/config.c:65
#4 0x55c837ed1ef4 in load_configuration ../../i3/src/config.c:230
#5 0x55c837f0a8d0 in main ../../i3/src/main.c:539
#6 0x7fb63ae042b0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202b0)
This introduces memory usage by one copy of the config file, which is an
acceptable trade-off for being able to easily revert data loss.
The default config is 6KB, user configs will be in the same ballpark.
fixes#2856
Subset comparison was introduced with the rather large commit
bf3cd41b5d, but I now think we should use
equality.
In other words, the following key binding:
bindsym Mod4+x nop Mod4+x
previously would have been triggered when pressing Mod3+Mod4+x.
Strictly speaking, this is a change of behavior, but it breaks none of our
tests, and using equality instead of subset comparison enables more use-cases.
fixes#2002
This patch fixes the issue #2511(https://github.com/i3/i3/issues/2511).
1). Memorize the marks, but only call con_mark once the container has finished parsing. (Credit: This is @Airblader's patch.)
2). Add a test case 267-regress-mark-restart.t for regression test to check if mark and restart command crash i3.
This introduces the flag --exclude-titlebar for mouse bindings which
allows bindings like
bindsym --whole-window --border --exclude-titlebar button3 focus
fixes#2347
With this PR the 'layout toggle' command can be passed any
combination of valid layout keywords as arguments. They will
be activated one after another each time you issue the command,
advancing from left to right always selecting the layout after
the currently active layout or the leftmost layout if the active
layout is not in the argument list.
This PR also incorporates the feature request from #2476.
With commit d58dbc3 we started ignoring Expose events in a sequence
except for the last one. Since we only copied the affected part of
the window in the Expose event handler, this caused incorrectly
rendered window decorations.
Instead of reverting to the old behavior, we now copy the entire window
content on this single, last event with the following rationale:
- It's cheaper to copy a larger chunk once than multiple smaller
chunks doing one server roundtrip each.
- That's how we do it when rendering out decoration on decoration
changes as well.
fixes#2683
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
Previously rendering marks and the title were skipped if the title is empty. With marks
this is obviously wrong, with the title it is also wrong because title_format might be
set.
Doing a hard exit() is a rather harsh action for something i3 can handle
perfectly fine and is only meant to be a check to make debugging easier
for users in certain situations.
Thanks to @psychon for pointing this out during the review of PR #2624.
This commit extends this change to all other occurences of Expose events
within i3.
While defining the same mode usually wouldn't hurt and, in fact, the old behavior
allows to split the definition of a binding mode into several blocks, this
can lead to user errors where they accidentally define a mode twice and don't understand
why the mode behaves a certain way (this has been observed in real life :-)).
There's no good usecase for splitting a single binding mode into multiple blocks, thus
the new behavior is better.
fixes#2615
This commit is a rewrite of the popup dialogs used when i3 crashes. We now
use our draw_util suite and both properly react to EXPOSE events and clean
up the windows when the handler exits.
As a side-effect, this fixes#2422
This commit introduces proper support for the minimum size on floating
windows by ensuring that it is respected during mapping, later changes as
well as resizes.
Furthermore, this commit fixes minor issues with how the hints are handled
during calculations.
fixes#2436
This comes with the intentionally undocumented --disable-randr15 command
line flag and disable-randr15 configuration directive. We will add
documentation before the release if and only if it turns out that users
actually need to use this flag in their setups. Ideally, nobody would
need to use the flag and everything would just keep working, but it’s
better to be safe than sorry.
fixes#1799
xcb_draw_line is unused since commit
d7f9700ba4
xcb_draw_rect is unused since commit
a79d33fc7f
xcb_raise_window is unused since commit
7208d01048
xcb_warp_pointer is unused since commit
755c618cd4
Fix memory leaks when executing 'i3 --moreversion'.
=================================================================
==14852==ERROR: LeakSanitizer: detected memory leaks
Direct leak of 159 byte(s) in 1 object(s) allocated from:
#0 0x7fea40855602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x4c4c4a in smalloc ../../i3/libi3/safewrappers.c:24
#2 0x4c3aee in ipc_recv_message ../../i3/libi3/ipc_recv_message.c:61
#3 0x44dc2e in display_running_version ../../i3/src/display_version.c:94
#4 0x472947 in main ../../i3/src/main.c:269
#5 0x7fea3d0c982f in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x2082f)
Direct leak of 39 byte(s) in 2 object(s) allocated from:
#0 0x7fea40855602 in malloc (/usr/lib/x86_64-linux-gnu/libasan.so.2+0x98602)
#1 0x7fea3d11f7d7 in vasprintf (/lib/x86_64-linux-gnu/libc.so.6+0x767d7)
SUMMARY: AddressSanitizer: 198 byte(s) leaked in 3 allocation(s).
https://llvm.org/bugs/show_bug.cgi?id=30353 was filed for the unintended
line break between in e.g. “TAILQ_ENTRY(foo)\nbar;”.
Until that’s fixed or a workaround is known, we’ll live with line
breaks. To make it a bit easier for readers to see what’s going on, I
added extra line breaks around each such struct member/variable
definition, so that they at least visually are a single unit.
fixes#2174
Fix the issue #2421 (https://github.com/i3/i3/issues/2421).
floating_enable() invokes tree_close_internal() to free con->parent.
After con->parent is freed in tree_close_internal() but before con->parent is reassigned by the caller, con->parent may be dereferenced and causes i3 crash.
The backtrace below is an example.
The already-freed pointer is dereferenced again through the pointer "focused" in x_push_changes().
Reassign con->parent before calling tree_close_internal() to fix this use-after-free bug.
0x0000000000416372 in con_get_workspace (con=0x7ab9c0) at ../i3/src/con.c:375
0x0000000000416103 in con_has_managed_window (con=0x7ab9c0) at ../i3/src/con.c:266
0x000000000042b413 in x_push_changes (con=0x78d190) at ../i3/src/x.c:1132
0x0000000l0004533e8 in tree_render () at ../i3/src/tree.c:504
0x0000000000452b4f in tree_close_internal (con=0x7b67c0, kill_window=DONT_KILL_WINDOW, dont_kill_parent=false, force_set_focus=false)
../i3/src/tree.c:314
0x00000000004196f0 in con_on_remove_child (con=0x7b67c0) at ../i3/src/con.c:1801
0x0000000000452eb7 in tree_close_internal (con=0x783840, kill_window=DONT_KILL_WINDOW, dont_kill_parent=false, force_set_focus=false)
../i3/src/tree.c:364
0x0000000000431516 in floating_enable (con=0x7ab9c0, automatic=false) at ../i3/src/floating.c:183
0x0000000000431eed in toggle_floating_mode (con=0x7ab9c0, automatic=false) at ../i3/src/floating.c:379
0x0000000000420d92 in cmd_floating (current_match=0x679a20 , cmd_output=0x679aa0 , floating_mode=0x7ab8c0 "toggle")
../i3/src/commands.c:1088
0x000000000043e5ae in GENERATED_call (call_identifier=60, result=0x679aa0 ) at include/GENERATED_command_call.h:486
0x000000000043ee19 in next_state (token=0x675d70 ) at ../i3/src/commands_parser.c:187
0x000000000043f2fb in parse_command (input=0x7b4fe0 "floating toggle", gen=0x0) at ../i3/src/commands_parser.c:308
0x00000000004125f8 in run_binding (bind=0x784260, con=0x0) at ../i3/src/bindings.c:792
0x000000000042bace in handle_key_press (event=0x7a01a0) at ../i3/src/key_press.c:33
0x000000000044e6aa in handle_event (type=2, event=0x7a01a0) at ../i3/src/handlers.c:1420
0x0000000000439533 in xcb_check_cb (loop=0x7ffff532f8e0, w=0x68c140, revents=32768) at ../i3/src/main.c:133
0x00007ffff5125d73 in ev_invoke_pending () from /usr/lib/x86_64-linux-gnu/libev.so.4
0x00007ffff51293de in ev_run () from /usr/lib/x86_64-linux-gnu/libev.so.4
0x0000000000439418 in ev_loop (loop=0x7ffff532f8e0, flags=0) at /usr/include/ev.h:835
0x000000000043d51d in main (argc=3, argv=0x7fffffffe0a8) at ../i3/src/main.c:913
Including config.h is necessary to get e.g. the _GNU_SOURCE define and
any other definitions that autoconf declares. Hence, config.h needs to
be included as the first header in each file.
This is done either via:
1. Including "common.h" (i3bar)
2. Including "libi3.h"
3. Including "all.h" (i3)
4. Including <config.h> directly
Also remove now-unused I3__FILE__, add copyright/license statement
where missing and switch include/all.h to #pragma once.
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.
The idea was to ensure the symbol would always be present. For that, we need
__attribute__((used)), not __attribute__((unused)). Further, ensure the
variable has static storage, as the used attribute only applies to variables
with static storage. See also http://stackoverflow.com/a/29545417/712014
We strive to avoid conditional compilation in i3 as much as possible.
cairo and pangocairo have been around long enough in the versions that
we need that it’s time to unconditionally depend on them.
Also update DEPENDS with the last-known-good-versions while at it.
We call scratchpad_show() on _NET_ACTIVE_WINDOW requests if the request
came from a pager. This is consistent with the i3 »focus« command because
we assume the user requested to see the window, so we do the only
sensible thing.
fixes#2455
When receiving an ENTER_NOTIFY event on a dock client we returned as to not
focus the dock client (cf. #321 and #323). However, we still need to check
for crossing output boundaries and if that happened focus the new output.
Otherwise it can happen that the cursor is on a different output than the
focused output. When opening a window, this would open it on the old output
and then warp the mouse there. This effect will be even worse if the window
is immediately moved with 'move position mouse' as the window will end up
in its correct position on the new output and the cursor warped to the old
output.
relates to #2081
This commit correctly handles colormaps by
* Using the static default colormap we determine on startup if the
con has the corresponding depth. This avoids creating pointless
colormaps.
* Not freeing the default colormap to not have stray colormaps on
containers. This fixes an issue with certain programs such as xwd.
* Creating a custom colormap when necessary and freeing it when the
container is killed.
fixes#2435
Before this commit, i3 only compared the user-specified modifiers and
incorrectly ignored the resolved modifiers (such as the numlock
fallback).
While at it, also fix the testcase which treated numlock as a momentary
modifier, whereas it really is a latched modifier.
fixes#2418
Previously, we always discarded the NumLock bit when looking up key
bindings for key press events, and we always grabbed every keycode with
and without the NumLock modifier.
With this commit, the NumLock bit is no longer discarded: since the
previous commit 3bd5e6e5c8 we can
correctly look up key bindings with/without the NumLock bit, as both
variants are stored in |keycodes_head|.
Further, before adding the NumLock fallback (resulting in grabbing the
keycode with the NumLock modifier), we now check whether the key has the
same meaning when NumLock is enabled. This correctly distinguishes the
KP_End vs. KP_1 case, i.e. one can now use the following key bindings:
# No longer accidentally triggered when pressing KP_1.
bindsym KP_End nop KP_End
# Properly distinguished now:
bindsym KP_End nop KP_End
bindsym Mod2+KP_1 nop KP_1
fixes#2346
Orestis Floros