Context:
Motif hints [1] allow applications to request specific window manager
frame decorations. Most applications like alacritty, chromium, and
godot, use the hints as a binary flag, setting or un-setting
`MWM_DECOR_ALL`.
Previously [2], we had disallowed applications to set the "normal"
border style through motif hints. This effectively meant that users that
had set `default_border pixel` would not see applications spawning with
normal decorations [3].
However, that meant that applications like godot [4] could not toggle
their border between none and normal so the behaviour changed with
v4.21 [5].
That change however also allowed applications to override the default
none/pixel border style the user set. For example, alacritty can be
configured to either have all or no decorations [6] and they always set
the motif hint on startup, completely overriding i3 user's preference:
1. If decorations are disabled with alacritty's config then they will
override `default_border normal` and no title will be used.
2. If decorations are enabled (also the default behavior) with
alacritty's config then they will override `default_border pixel` and
a title will be used.
This patch redefines how we interpret motif hints. When a client sets
`MWM_DECOR_ALL`, we interpret it as "the maximum decoration the user has
allowed for this window". I.e., if a client was all decorations and the
user expects the window to not have a title, we don't include the title
in "all" decorations.
The user's preference is determined by these:
1. For new tiling windows, as set by `default_border`
2. For new floating windows, as set by `default_floating_border`
3. For all windows that the user runs the `border` command, whatever is
the result of that command for that window.
Example:
- User opens new tiling window with `default_border pixel` => maximum
decoration = PIXEL
- Window requests all/title decorations => i3 enforces the user maximum
decoration, PIXEL (no change)
- Window requests no decorations => i3 accepts it and sets border to
NONE, maximum decoration remains PIXEL
- User toggles the border, next style is NORMAL => maximum decoration is
now NORMAL
- Window requests no decorations => i3 accepts it and sets border to
NONE
- Window requests all/title decorations => i3 accepts it and sets the
maximum border, NORMAL
- User toggles the border, next style is NONE => maximum decoration is
now NONE
- Window requests all/title decorations => i3 enforces the user maximum
decoration, NONE (no change)
With this, we will still allow behaviour where windows can toggle their
border style with motif hints [4][7].
Reference/footnotes:
[1]: https://linux.die.net/man/3/vendorshell
[2]: https://github.com/i3/i3/pull/2386
[3]: Notice how there is apparently a gap because `default border none`
settings would not be respected if an application wanted just "border"
decorations but this was never reported, probably because of the rare
conjunction of applications requesting that and users defaulting to none
borders.
[4]: https://github.com/godotengine/godot/issues/40037
[5]: https://github.com/i3/i3/pull/5135
[6]: Set by an underlying library here:
fafdedfb7d/src/platform_impl/linux/x11/util/hint.rs (L113-L142)
called by alactitty here:
4ddb608563/alacritty/src/display/window.rs (L341)
[7]: https://github.com/i3/i3/issues/3678Closes#3678Fixes#5149
The only place where this matters is with command `border toggle` which
cycles through them. Luckily, the behaviour does not change because the
order is the same with the new enum.
Fixes#2643
Inner drop region behaves like move to mark.
The outer region is close to the edge (currently 30px from the edge).
This will place the container as a sibling in the given direction within
the parent container. If the move direction goes against the orientation
of the parent container, tree_move() is called.
Contributors:
Co-authored-by: Orestis Floros <orestisflo@gmail.com>
See #3085
- Inner drop region behaves like move to mark
- Handle workspaces
- Fix crash when target closes
- Initiate tiling drag from titlebar
- Hide indicator until container is dragged outside of original position
- Calculate outer_threshold using percentages instead of fixed pixel
values
- Emit 'move' event properly
- Don't focus previously unfocused containers
- Use tree_split() on different orientation
- Fix redundant split containers
- DT_PARENT
- Readability & optimizations
- Limit parent threshold by render_deco_height()
- Tests
- Fullscreen container handling
- Initiate drag from title bar
- Fix issue of EnterNotify events still triggering after drag_callback
is called
- Include decorations for drop target calculation
Co-authored-by: Michael Forster <email@michael-forster.de>
See #2178
- Original implementation of tiling drag + indicator window
> A container can be dragged by the title bar to one of the four sides
> of another container. That container will then be split either
> horizontally or vertically.
Co-authored-by: Tony Crisci <tony@dubstepdish.com>
See #2653
- Original implementation of outer/inner drop region indicator:
> There are two drop regions per direction.
>
> The inner region is closer to the center of the window. Dropping on
> this region will split the target container and put the container
> within the split at the given direction beside the target container.
>
> The outer region is close to the edge (currently 30px from the edge).
> This will place the container as a sibling in the given direction within
> the parent container.
>
> Dropping into the outer region moves the con beside the target. If the
> move direction goes against the orientation of the parent container, the
> con moves out of the row.
- Fix crash: Ignore containers without a managed window (eg i3bar)
The issue at [0] was opened and I just took a stab at it. I have no
prior experience with pcre and pcre2, but using [1,2] I hacked together
something that seems to work. Next, Michael told me to turn that
patch/hack into a PR, so here we are.
The dependency in meson.build now uses version:'>=10', but this is more
a random guess than actual knowledge.
There was a while loop in regex_new() that dealt with an error when pcre
was not compiled with UTF-8 support. This loop uses a magic constant of
32 for the error code. I just dropped this loop, because I was just
writing a hack and did not intend to turn this into a PR. Also, a quick "grep
32 /usr/include/pcre.h" does not find anything useful, so... *shrug*
pcre_study() was removed without replacement, so the corresponding code
is also simply removed.
Testing done: The test suite passes for me. YMMV.
[0]: https://github.com/i3/i3/issues/4682
[1]: https://www.pcre.org/current/doc/html/pcre2api.html
[2]: https://www.pcre.org/current/doc/html/pcre2demo.html
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes: https://github.com/i3/i3/issues/4682
Other approaches would be:
- Slow/fast pointer technique.
- Using a set/associative map to save 'seen' nodes. i3 does not have
such data structure.
Counting the total amount of windows is the simpler to implement.
I've also extracted the logic in a function and re-used it in render.c.
Fixes#4404
Imagine you are a happy i3 user and want to also write patches for i3.
You use "Xephyr :1" to get another X11 server and then start your newly
build i3 in it with "DISPLAY=:1 ./i3". You test your changes and
everything seems fine. You are happy. Later that day, you try to log
out, but the $mod+Shift+e key binding from the default config no longer
works. i3-msg cannot connect to the IPC socket because "No such file or
directory". What is going on?
The problem boils down to $I3SOCK having something like two meanings.
When i3 starts, it sets the environment variable $I3SOCK to the path of
its IPC socket. That way, any process started from i3 inherits this and
i3-msg knows how to talk to i3. However, when this variable is already
set when i3 starts, then i3 will replace the existing socket. Thus, in
the earlier experiments, the "separate i3" that was used for
experimenting stole the "main i3"'s socket and replaced it with its own.
When it exited, it deleted that socket.
This commit adds half a work around to this problem: When creating the
IPC socket, i3 will now first try to connect() to the socket. If this
succeeds, it will complain and refuse to use this socket. If the
connect() call fails, it will proceed as usual and create the socket.
Note that trying to connect() to a socket that no process listens on
will fail. Thus, this new code only really "triggers" when some process
is actively listening on this socket and accepting connections.
Example output for when the socket is already in use:
$ I3SOCK=/tmp/sdfdsf DISPLAY=:2 ./i3
31.10.2021 17:03:55 - [libi3] ERROR: Refusing to create UNIX socket at /tmp/sdfdsf: Socket is already in use
31.10.2021 17:03:55 - ERROR: Could not create the IPC socket, IPC disabled
This commit sadly only provides part of the solution. i3 will still
delete the socket when shutting down, even if it failed to create the
IPC socket. Thus, the ipc socket will still break, but now only later.
This will be fixed separately.
First-step-towards-fixing: https://github.com/i3/i3/issues/4381
Signed-off-by: Uli Schlachter <psychon@znc.in>
We do this by adding to included_files as i3 processes the configs.
This should allow for easy debugging, without having to change how i3 processes
config files.
related to #4192
This criterion matches all open windows, as a more readable (and
correct) version of the 'class=".*"' criterion (more correct because
it'll also match windows which don't have WM_CLASS set yet).
This feature defaults to off, and can be turned on for individual windows,
or (with for_window) for all new windows. See the userguide change.
This commit is partially based on work by:
• Marius Muja
• mickael9
• Esteve Varela Colominas
• Bernardo Menicagli
The implementation uses wordexp(3) just like sway:
https://github.com/i3/i3/issues/1197#issuecomment-226844106
Thanks to jajm for their implementation at
bb55709d0a
This required refactoring the config parser to be re-entrant
(no more global state) and to return an error instead of dying.
In case a file cannot be opened, i3 reports an error but proceeds with the
remaining configuration.
Key bindings can be overwritten or removed using the new --remove flag of the
bindsym/bindcode directive.
All files that were successfully included are displayed in i3 --moreversion.
One caveat is i3 config file variable expansion, see the note in the userguide.
fixes#4192
"Set" the wallpaper during startup only sometimes
Since commit 4f5e0e7, i3 would take a screenshot and set that as the
background pixmap of the root window during startup. This is the easy
part of setting a proper X11 wallpaper.
The code in question was added because something either set the
background pixmap of the root window to NONE or the X11 server was
started with "-background none". This is apparently done by default by
e.g. gdm to avoid some flickering while the X11 server starts up.
This commit makes this code conditional: Only when no wallpaper is
detected is a screenshot taken.
Since I could not find any way to query the background of a window, a
more direct approach is taken to detect this situation: First, we find
some part of the root window that is not currently covered. Then we open
a white window there, close it again and grab a screenshot. If a
wallpaper is set, the X11 server will draw this wallpaper after the
window is closed and something else will be visible in the screenshot.
However, the wallpaper could have a white pixel at the tested position.
Thus, this procedure is repeated with a black window.
Only when this procedure produces two different pixel values is a
screenshot taken and set as the wallpaper.
Fixes: https://github.com/i3/i3/issues/4371
Fixes: https://github.com/i3/i3/issues/2869
Signed-off-by: Uli Schlachter <psychon@znc.in>
i3 actually manages to have two different cairo surfaces referring to
the same drawable. One comes from the code in draw_util. The second is
temporarily created while rendering text via draw_text(). No idea how
well cairo handles this case.
This commit instead changes the code to pass the already existing cairo
surface from the caller through.
This might or might not fix https://github.com/i3/i3/pull/4357. My
thinking here is that cairo now knows the actual size of the drawable
and thus does not clip the drawing to a smaller size.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Motivation:
• faster builds (on an Intel Core i9-9900K):
( ../configure --disable-sanitizers && make -j8; )
19,47s user 2,78s system 395% cpu 5,632 total
( meson .. -Dmans=true -Ddocs=true -Dprefix=/usr && ninja; )
38,67s user 3,73s system 1095% cpu 3,871 total
• more approachable build system configuration in the
python-esque meson domain specific language instead of
the autotools m4 macro language
• built-in language server support thanks to ninja:
the required compile_commands.json is built automatically
and only needs to be linked from the source dir, e.g.:
ln -s build/compile_commands.json .
Changes:
• the embedded vcs version info format changed from e.g.
4.18-282-gabe46f69 (2020-05-16, branch "next")
to:
4.18-282-gabe46f69
I think it’s better to lose a little bit of detail for
the gained cleanliness of using meson’s vcs_tag()
• Drop unused xcb-event dependency.
• We can no longer enable sanitizers and debug options
based on whether we are in a release or non-release build,
because our new version logic runs at ninja build time,
not at meson configure time.
The new behavior is probably for the better in terms of
what people expect, and we can make the CI use address sanitizer
explicitly to ensure it is still exercised.
• We lose the AX_EXTEND_SRCDIR behavior, i.e. including the
path component of the parent of the source dir in all paths.
This was a trick we used for easier debugging, so that stack
traces would contain e.g. ../i3-4.18.1/src/main.c, instead of
just src/main.c.
The other mechanism (_i3_version symbol) that we have for including
the version number in the “backtrace full” (but not merely
“backtrace”) output of gdb still works.
• Release tarballs now use tar.xz. Why not.
Migration plan
This commit adds the meson build files to the tree, but does not remove
autotools yet. For the development phase, we will keep both build systems
functional (and built on travis).
Then, just before the i3 v4.19 release, we will remove autotools from the tree
and the release tarball will require meson to compile.
This way, we incentivize maintainers to change, while also offering them an easy
way out (if desired) by reverting the most recent commit. In practice, switching
a distribution package from autotools to meson should only be a few line change,
easier than applying the provided patch :). Take a look at the debian/ changes
in this commit for an example.
meson is broadly available everywhere that i3 is available: Both xorg-server and
systemd gained meson build files in 2017, so we can follow suit:
https://anholt.livejournal.com/52574.htmlhttps://in.waw.pl/~zbyszek/blog/systemd-meson.html
How do I?
For producing a coverage report, enable the b_coverage meson base option
and run ninja coverage-html:
% cd build
% meson .. -Db_coverage=true
% ninja
% ninja test
% ninja coverage-html
See also https://mesonbuild.com/howtox.html#producing-a-coverage-report
For using the address sanitizer, memory sanitizer or undefined behavior
sanitizer, use the b_sanitize meson base option:
% cd build
% meson .. -Db_sanitize=address
% ninja
See also https://mesonbuild.com/Builtin-options.html#base-options
related to #4086
This works better with meson, where .h files can be declared as being part of an
executable easily, but I couldn’t find a way to declare
e.g. include/atoms.xmacro as a dependency.
related to #4086
- Split cmd_bar into 2 functions, improving errors and reducing strcmps
- Only update barconfig when something has changed
- Only update barconfig for the specific bar that has changed
Fixes#3958
Fixes#4039
Crash with docking clients where the floating field is set even though
floating_enable refuses to make them floating.
See issue for example with logs.
This is similar to #3820 but does not use qsort but an insertion sort in
con_attach.
Since each bar block automatically gets its own incremental bar id,
bards end up being sorted according to their definition order in the
config file.
For i3bar, the WM_CLASS is modified to include an instance name which
depends on the bar_id. This could be useful for other reason, e.g. users
targeting a specific bar instance.
Fixes#3491
