This had pretty much identical behaviour to hide_edge_borders which made
it confusing. The `hide_edge_borders smart_no_gaps` implementation has an extra check
which fixes#5406.
Enforces a rule that we have followed for years now. Yes, the diff is
quite big but we get it over with once and we prevent having to nit-pick
future PRs.
If a window occupies the entirety of its workspace vertically and/or horizontally, pass it the _NET_WM_STATE_MAXIMIZED_{HORZ, VERT} atoms. This helps applications like Google Chrome draw the tab bar correctly and handle tab clicks correctly (see https://crbug.com/1495853).
This change is based on work from @yshui in #2380.
Grabing the pointer produces a `GrabFrozen` error in applications that
are run from key bindings. Since we don't need the pointer in such
cases, we can change the call to use ASYNC. This seems to be a
historical leftover.
I've tested locally that these still work:
- bindsym $mod+x ...
- bindsym --release $mod+x ...
- bindsym $mod+button1 ...
- bindsym --release $mod+button1 ...
- bindsym --release $mod+x exec program that grabs the keyboard
now works (see original issue)
Even in the main branch, I actually couldn't get `import` and `xdotool`
to fail with the pointer being frozen, potentially because these
programs wait a bit for the pointer to be unfrozen like i3lock does.
This patch came up in
https://github.com/i3/i3/issues/5735#issuecomment-1781321011
I wonder why the pointer is actually grabbed.
The argument I change in `xcb_grab_key` there, is `pointer_mode`, from
https://www.x.org/releases/X11R7.7/doc/man/man3/xcb_grab_key.3.xhtml:
```
pointer_mode
One of the following values:
XCB_GRAB_MODE_SYNC
The state of the keyboard appears to freeze: No further keyboard events are generated by the server until the grabbing client issues a releasing AllowEvents request or until the keyboard grab is released.
XCB_GRAB_MODE_ASYNC
Keyboard event processing continues normally.
```
I traced via `git blame` the usage of `xcb_grab_key` throughout 14 years
of i3 development and it seems that `pointer_mode` was always set to
`XCB_GRAB_MODE_SYNC`, going all the way back to
b664456706.
Fixes#5735
When the font from testcase's config exists on the system,
load_configuration() does not fallback to a 'fixed' one resulting in a
fail of this case.
The fallback scenario is added as well.
Instead of creating a graphics context for every surface_t, this commit
adds a cache that allows to "remember" up to two GCs. Thus, the code
uses less GCs. When a GC from the cache can be used, this also gets rid
of a round-trip to the X11 server. Both of these are tiny, insignificant
savings, but so what?
Since GCs are per-depth, this code needs access to get_visual_depth().
To avoid a code duplication, this function is moved to libi3.
Fixes: https://github.com/i3/i3/issues/3478
Signed-off-by: Uli Schlachter <psychon@znc.in>
Unfortunately, grabbing / ungrabbing doesn't seem to work correctly in
xvfb so we can't really test this.
I also fixed the deduplication code in bindings_get_buttons_to_grab().
Having just a single fork is beneficial, as it preserves the approprate
parent information for the children of i3, which is useful in some
scenarious e.g. when a child wants to do something on the wm's exit
(possible via `prctl(PR_SET_PDEATHSIG, ...)`).
Moreover, this is a zero-cost benefit: i3 is already using libev with
the default loop, which automatically reaps all the zombie children even
when there is no corresponding event set.
Resolves#5506
Also updates the function to use proper types, const and style.
The warning:
../i3/i3-input/main.c: In function ‘finish_input’:
../i3/i3-input/main.c:187:13: warning: ‘__builtin_strncat’ specified bound depends on the length of the source argument [-Wstringop-overflow=]
187 | strncat(dest, command, inputlen);
| ^
../i3/i3-input/main.c:175:20: note: length computed here
175 | int inputlen = strlen(command);
Which is triggered because gcc thinks it's bad that `input_len` (the
length of the source in the copy) is used instead of a length that is
inside the limits of the allocated size for the destination. However, in
practice, `full_len` is always than `input_len`.