This causes test breakage when the developer/tester is running the tests
in i3, as the actual active instance socket is used instead of the test
instance.
Besides breaking tests, this is quite dangerous as tests like 319-gaps.t
will replace the **actual** config of the user (i.e.
~/.config/i3/config) instead of the current test config.
Broken after #5987
This was originally mentioned in #3085 but left for a future PR.
One of the noticeable limitations is that pressing the modifier while
the drag is already initiated, will not swap the containers but instead
cancel the drag. This is because of how `drag_pointer()` is written and
would be quite an involved case to handle it.
The crash was brought up in a comment in
https://github.com/i3/i3/discussions/6076#discussioncomment-9536969
The cause is that the command criteria are matching a window in the
scratchpad. In that case, the assertion in get_output_for_con() fails.
That happens because there is no `Output` for the `Con` output of a
scratchpad window.
I've decided to *not* remove the offending assertion but rather rely on
the caller not using the function with internal containers. My reasoning
is:
1. If get_output_for_con can return NULL then the caller will either
segfault (which is worse) or needs to check the return for NULL.
2. The case where the return can be NULL is already known, it happens
for internal containers.
3. Therefore, the caller should already prevent the situation with a
call to con_is_internal(). Thus, the `assert`ion can remain.
There is also the potential fix of con_get_workspace returning some
arbitrary output (e.g. first in the list or currently focused one)
instead of NULL. This can lead to more tricky to catch bugs.
This adds some detail to the workspace events documentation and is
written along the same lines as the window events documentation. This
was brought up in [#4392 (issue)](https://github.com/i3/i3/issues/4392).
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.
