Without this change, I see the following (harmless but annoying)
compiler warnings when building i3 after `meson setup build`:
[3/106] Compiling C object libi3.a.p/libi3_g_utf8_make_valid.c.o
In file included from /nix/store/gi4cz4ir3zlwhf1azqfgxqdnczfrwsr7-glibc-2.40-66-dev/include/bits/libc-header-start.h:33,
from /nix/store/gi4cz4ir3zlwhf1azqfgxqdnczfrwsr7-glibc-2.40-66-dev/include/stdio.h:28,
from ../include/libi3.h:17,
from ../libi3/g_utf8_make_valid.c:20:
/nix/store/gi4cz4ir3zlwhf1azqfgxqdnczfrwsr7-glibc-2.40-66-dev/include/features.h:422:4: warning: #warning _FORTIFY_SOURCE requires compiling with optimization (-O) [-Wcpp]
422 | # warning _FORTIFY_SOURCE requires compiling with optimization (-O)
| ^~~~~~~
This makes it possible to build i3 (for development)
on any system on which Nix can be installed (= most Linux systems).
For example, I start Emacs using `nix develop --command emacs`
and that Emacs process is in an environment with all i3 build deps.
See also:
https://michael.stapelberg.ch/posts/2025-07-27-dev-shells-with-nix-4-quick-examples/
This file is provided best-effort, but PRs are welcome.
While users can already run `nix develop nixpkgs#i3`,
for nix-direnv integration it is required to declare a flake.nix
in the project directory (otherwise direnv cannot find it).
similar to https://github.com/i3/i3lock/pull/372
related to https://github.com/i3/i3/pull/6549
Rename 554-crash-floating-enable.t to 554-commands-crash-for-window.t
and convert it to a table-driven test. This isn't based on any existing
bugs, just to prevent unexpected failures or change of behaviour.
These were supposed to fail quickly instead of hanging,
but in practice that is prone to flakiness.
Let’s remove the timers to reduce flakiness.
related to https://github.com/i3/i3/issues/3009
This test was flaky because it issued a 'kill' command through i3
and assumed that focus would immediately be different afterwards.
However, the 'kill' command (via x_window_kill) only results in an
xcb_destroy_window() request to X11, not in a focus change.
Only when i3 processes the X11 server response to this request
will focus change back to the window that should be changed with
the 'border normal 0' command.
related to https://github.com/i3/i3/issues/3009
When running 'floating toggle' (or enable/disable) on an empty
workspace, the focused container is the workspace itself, which has
window=NULL. The command would call run_assignments(workspace->window),
which would pass NULL to match_matches_window(), causing a crash when
trying to access window->id.
Add a NULL check at the beginning of `run_assignments` to immediately
skip assignments for that case.
Fixes: #6561
This reverts commit c5d0d5e837.
By starting i3 in a systemd unit, the user’s environment is lost.
This breaks too many workflows.
Blanket-importing the environment using systemctl import-environment
(without arguments) is explicitly discouraged in the systemctl man page.
It’s not clear how to fix this issue cleanly, so revert to unblock the release.
related to https://github.com/i3/i3/issues/5186
On Linux systems using systemd, we should activate graphical-session.target.
We conceptually need our i3.desktop file to do a
blockingly-run-via-systemd action (this is what scopes the activation of
graphical-session.target to the X session), and shipping an i3.service
is the best way to define the systemd unit we use for that.
Based on https://github.com/i3/i3/pull/5591 by David Sansome.
fixes https://github.com/i3/i3/issues/5186
I noticed that the Nix build does not actually work when using the
“#!/usr/bin/env $^X” shebang because /usr/bin/env is not present in the
Nix build sandbox.
$Config{perlpath} is always absolute, so let’s prefer that.
Tested both inside and outside a Nix build sandbox.
related to https://github.com/i3/i3/pull/6537
Calling `feature->import(":5.10")` without loading feature.pm first
produces a warning in Nix derivation sandbox environments:
Attempt to call undefined import method with arguments (":5.10")
via package "feature" (Perhaps you forgot to load the package?)
Unlike the `strict` and `warnings` packages, which are loaded
by the use statements at the top of i3test.pm, the `use v5.10` line
does not load the `feature` package, but is handled directly by perl(1).
This commit adds explicit require statements for correctness.
The test creates a fake i3-msg Perl script at runtime. Previously it
used `#!/usr/bin/env perl` as the shebang, but this can fail in certain
build environments (e.g., Nix sandboxed builds) where the `perl` found
via `/usr/bin/env` may not have the same module paths as the `perl`
running the test suite.
Use `$^X` instead, which contains the path to the Perl interpreter
currently running the test. This ensures the generated script uses the
same Perl with the same `PERL5LIB` environment, guaranteeing that
`JSON::XS` and other required modules are available.
Before this commit, we used setlocale(LC_NUMERIC, "");,
but that is not correct because it doesn’t nest:
load_layout.c (sets LC_NUMERIC=C) calls con_mark(),
which calls ipc_send_window_event() (sets LC_NUMERIC=C),
which calls setlocale(LC_NUMERIC, ""); when returning,
but now load_layout has LC_NUMERIC set per the environment,
whereas the function expects to remain in LC_NUMERIC=C.
Using newlocale and uselocale just swaps handles,
which is a little cleaner than querying the locale with
strdup(setlocale(LC_NUMERIC, NULL)); and restoring it later.
The test only fails with certain locales, e.g. LC_NUMERIC=de_DE.
I don’t think it’s important to set a locale in our test runner,
(which locales are available is very system-dependent),
as I am personally regularly testing with LC_NUMERIC=de_DE ;)
fixes https://github.com/i3/i3/issues/6391
This fixes issues with display link displays not working on i3 and
should not affect any other features from my testing.
Co-authored-by: FedGuy699 <bytebustersco@gmail.com>
We only added that for people who use doxygen to browse code bases. That
was before the age of LSP support in editors, which does a much better
job of that nowadays.
Distributions like Fedora have for some reason started shipping the full
doxygen-generated HTML, which is many megabytes in size. This was never
our intent, so remove the file to prevent it.
fixes https://github.com/i3/i3/issues/6436
This PR is a pure linting and code cleanup effort with no functional
changes, focusing on improving code quality and consistency.
The bulk of the changes involve:
* Code Formatting: The entire codebase was reformatted after updating
our `clang-format` version.
* Compiler Warnings: Addressed `-Wsuggest-attribute` warnings from GCC
by applying `pure`, `const`, and `format` attributes where appropriate.
This helps the compiler with optimizations and bug detection.
* Code Modernization:
* Variable declarations were moved closer to their first use or into
tighter scopes.
* `memset` calls were replaced with C99 zero-initializers (`= {0}`).
* Redundant `struct` keywords, unnecessary type casts, and some
superfluous `return` statements were removed.
* CI Adjustments: The GitHub Actions workflow was updated to correctly
apply compiler flags for both GCC and Clang.
The command and config parsers both used a similar stack implementation
for handling tokens. This resulted in duplicated code.
This commit extracts the common stack implementation (push/get/clear
functions for strings and longs) into a new `parser_util` module.
This resolves a long standing TODO comment.
exec* calls return when an error occurs, this is unexpected but would
still leave the forked process in a broken state. This commit fixes that
by ensuring they are followed by an immediate exit.
In theory, if `/proc/sys/kernel/core_pattern` is 1024 or more bytes, the
null character terminating the buffer can be overwritten.
Note: Found with [bugfinder](https://github.com/stanek-michal/bugfinder)
Before the xcb_randr_get_crtc_info() call fails, `new` has been already
added to `outputs with `TAILQ_INSERT_TAIL(&outputs, new, outputs);`.
Note: Found with [bugfinder](https://github.com/stanek-michal/bugfinder)
tree_move calls tree_flatten which can destroy redundant containers.
An example reproduction would be V[H[a V[b]]] where V[b] is focused
(parent of b) and a is moved away using the DT_PARENT target.
Note: Found with [bugfinder](https://github.com/stanek-michal/bugfinder)
Example in
https://github.com/i3/i3/actions/runs/18260895234/job/51988635887?pr=6502
`i3-log-for-124-move.t`:
```
../libi3/font.c:332:9: runtime error: signed integer overflow: 2147483641 + 11 cannot be represented in type 'int'
#0 0x5611ce962d65 in draw_text_xcb ../libi3/font.c:332
#1 0x5611ce962d65 in draw_text ../libi3/font.c:376
#2 0x5611ce95de20 in draw_util_text ../libi3/draw_util.c:219
#3 0x5611ce947e7a in x_draw_decoration ../src/x.c:751
#4 0x5611ce94f93a in x_push_node ../src/x.c:1097
#5 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#6 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#7 0x5611ce94e9d8 in x_push_node ../src/x.c:1204
#8 0x5611ce952e9b in x_push_changes ../src/x.c:1373
#9 0x5611ce922d1f in tree_render ../src/tree.c:468
#10 0x5611ce8d1bbb in handle_run_command ../src/ipc.c:220
#11 0x5611ce8c87fe in ipc_receive_message ../src/ipc.c:1481
#12 0x7effc262b64a in ev_invoke_pending (/lib/x86_64-linux-gnu/libev.so.4+0x564a) (BuildId: cfcffb10ff16734dcc7d31d002a90940abff0323)
#13 0x7effc262f22e in ev_run (/lib/x86_64-linux-gnu/libev.so.4+0x922e) (BuildId: cfcffb10ff16734dcc7d31d002a90940abff0323)
#14 0x5611ce809d48 in ev_loop /usr/include/ev.h:841
#15 0x5611ce809d48 in main ../src/main.c:1229
#16 0x7effc1e41ca7 (/lib/x86_64-linux-gnu/libc.so.6+0x29ca7) (BuildId: def5460e3cee00bfee25b429c97bcc4853e5b3a8)
#17 0x7effc1e41d64 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x29d64) (BuildId: def5460e3cee00bfee25b429c97bcc4853e5b3a8)
#18 0x5611ce80e770 in _start (/usr/src/i3/build/i3+0x230770) (BuildId: 181abde9a3dd28a8a4be68b90b9b710c8e280633)
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../libi3/font.c:332:9
```
Unrelated but I fixed the build fails in `next` because of a
false-positive:
```
In file included from ../include/all.h:40,
from ../src/commands.c:10:
../src/commands.c: In function ‘cmd_floating’:
../include/log.h:30:33: error: ‘%s’ directive argument is null [-Werror=format-overflow=]
30 | #define DLOG(fmt, ...) debuglog("%s:%s:%d - " fmt, __FILE__, __FUNCTION__, __LINE__, ##__VA_ARGS__)
| ^~~~~~~~~~~~~
../src/commands.c:1193:13: note: in expansion of macro ‘DLOG’
1193 | DLOG("should switch mode to %s\n", floating_mode);
| ^~~~
cc1: all warnings being treated as errors
ninja: build stopped: subcommand failed.
```
Inspired by #5384, but instead of just using the border width, this PR
reports the actual frame extents for the window, which may also include
the title bar (for floating windows and tiled windows in plain split
containers, but not for tiled windows in stacked/tabbed containers).
The existing `con_border_style_rect()` function should already handle
all configuration options which can affect the decoration sizes (if it
does not, that would also show up in other places); its result just
needs to be converted into the format used by the `_NET_FRAME_EXTENTS`
property.
This PR fixes#4292 probably in the best way possible (the reported
`_NET_FRAME_EXTENTS` values should always match the actual sizes of
window frame elements which are actually drawn into the X11 frame window
into which the client window is reparented). The only really problematic
case is with the stacked/tabbed containers, for which the title bar is
actually drawn into a completely separate window, therefore the title
bar size cannot be reported in `_NET_FRAME_EXTENTS` (actually I tried to
calculate the size of those decorations and add it to the top decoration
size, but that did not change the behavior of `picom`).
<details><summary>Large screenshots here (3840×2160)</summary>
Example of configuration with `hide_edge_borders smart` — a single
window does not have borders, so only the top frame size is non-zero:
but multiple windows have borders:
Changing border width works too (although with `border normal 8` you can
see that the top border overlaps the title text, because on the i3 side
that border does not really exists, and `picom` just draws it over; also
the pixel sizes reported by `xprop` and `xwininfo` are not identical to
what is specified in i3, because I use 168 dpi on this system, therefore
4 px in the i3 config = 7 dpx):
Handling of tabbed containers is less perfect though. Here is a single
tabbed container with `hide_edge_borders smart`, so it does not really
have a border — note that all frame extents are zero, and the titlebar
is rounded separately (although it could easily be excluded from
rounding, that does not really help much):
Once the border actually appears, you may notice that the top part of
the `picom` border actually gets drawn over the top part of the window,
partially obscuring the top line in this terminal (`picom` does not mind
that the top frame size is reported as 0):
Some examples of floating windows (no major problems there):
Options like `hide_edge_borders both` work too when gaps are removed
(although the resulting behavior with `picom` is probably not very
useful — the rounded border gets drawn only if all of the left, bottom
and right borders are present):
The same with `border pixel 8` (note that windows with only the top
border hidden still get the rounded border treatment by `picom`, but the
border overlaps the top part of the window):
</details>
---------
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
Co-authored-by: Orestis Floros <orestisflo@gmail.com>
