This fixes the following warnings on 32 bit systems
```
[60/108] Compiling C object i3.p/src_regex.c.o
In file included from ../include/all.h:40,
from ../src/regex.c:10:
../src/regex.c: In function ‘regex_new’:
../include/log.h:29:33: warning: format ‘%lu’ expects argument of type ‘long unsigned int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
29 | #define ELOG(fmt, ...) errorlog("ERROR: " fmt, ##__VA_ARGS__)
| ^~~~~~~~~
../src/regex.c:35:9: note: in expansion of macro ‘ELOG’
35 | ELOG("PCRE regular expression compilation failed at %lu: %s\n",
| ^~~~
[93/108] Compiling C object i3-input.p/i3-input_main.c.o
../i3-input/main.c: In function ‘finish_input’:
../i3-input/main.c:173:29: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 2 has type ‘size_t’ {aka ‘unsigned int’} [-Wformat=]
173 | printf("occurrences = %ld\n", cnt);
| ~~^ ~~~
| | |
| | size_t {aka unsigned int}
| long int
| %d
```
One case when this might be useful is when i3 is restarted and there are
children that terminate after the previous i3 instance shut down but
before the new one set things up.
Fixes#5756
While this initially worked fine, at some point these patches broke
because libcairo started calling shmget(2) - a syscall not covered by
any pledge promise - and a common pitfall when using pledge with
graphics-oriented applications.
Various attempts were made to fix them, but at some time they were
simply disabled in the OpenBSD port:
a4a9f41dd75a03c386ba
This seems pointless and creates needless friction both for the i3 team
who was willing to carry ugly code and for the OpenBSD ports maintainers
who had to disable that code again.
Let's abandon this experiment.
Commit 3ae5f31d0 introduced the I3SOCK environment variable. This
prevents us from having to call `i3 --get-socketpath'. In case the
variable doesn't exist, fall back to the old ways.
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
If there is no newline character at the end of the version option's
output, the next command line prompt is written left to the version,
rather than under it.
Add simple `if exists' construct in the subscribe function. This
prevents a somewhat cryptic warnings such as these:
Use of uninitialized value $type in hash element at
/usr/share/perl5/AnyEvent/I3.pm line 309.
We still warn the user, but it is much clearer as to what the cause is.
It now shows something like this:
Could not subscribe to event type 'foo'. Supported events are _error
barconfig_update binding mode output shutdown tick window workspace
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
Since there is no separate error handling the `SIGUSR2` signal is
registered to get the write return code after exiting the program.
Fixes#5958
---------
Signed-off-by: Andre Werner <andre.werner@systec-electronic.com>
eg if you have workspaces: { 1, 2:a, 2:b, 3 } and are on workspace 1,
then 'workspace next' should traverse 1 -> 2:a -> 2:b -> 3 -> 1 instead
of 1 -> 2:a -> 3 -> 1.
Fixes#4452
The [official build instruction][1] are deprecated on Meson 1.3.1.
These command:
mkdir -p build && cd build
meson ..
ninja
... work but will yield the following warning:
> WARNING: Running the setup command as `meson [options]` instead of `meson setup [options]` is ambiguous and deprecated.
Here's the correct way, according to the [meson documentation][2]:
mkdir -p build
meson setup build
meson compile -C build
meson install -C build
[1]: https://i3wm.org/docs/hacking-howto.html#_building_i3
[2]: https://mesonbuild.com/Quick-guide.html#compiling-a-meson-project
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
b66445670695f48f52988e2cc81d2ea7f03cf237.
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.
