| Age | Commit message (Collapse) | Author |
|---|
|
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).
|
|
Fixes #6062
|
|
|
|
|
|
|
|
The "Focus the next output" example was misleading, fixed the code and
added another comment to the previous code.
|
|
- Only recommend local perl library installation
- Update build instructions to match hacking-howto
|
|
See https://unix.stackexchange.com/a/581410, `read` needs a variable
name.
Came up in #5939
|
|
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.
|
|
See <https://github.com/i3/i3/issues/2664>.
|
|
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
|
|
|
|
|
|
Closes: #5523
Signed-off-by: Wesley Schwengle <wesleys@opperschaap.net>
|
|
Also remove outdated section about IRC
|
|
|
|
|
|
|
|
Default binding to move window down is $mod+Shift+k, not $mod+Shift+j.
Proof: https://github.com/i3/i3/blob/next/etc/config#L45
This commit reverts this pull request https://github.com/i3/i3/pull/4146
|
|
Closes #3818 (parent issue)
Fixes #1808
Fixes #2333
Fixes #2617
Fixes #3548
|
|
|
|
This does *not* go in the binding object to reflect the same hierarchy
of the config file: a mode is a collection of bindings.
Fixes #5323
|
|
Fixes #4878
|
|
|
|
This commit moves subtracting the global gaps from the workspace gaps:
previously, this calculation was done while parsing the configuration
(order dependent), now it’s done at workspace assignment evaluation time.
related to https://github.com/i3/i3/issues/3724
fixes https://github.com/i3/i3/issues/5253
|
|
This is the last remaining diff from the i3-gaps tree.
related to https://github.com/i3/i3/issues/3724
Tested using the following config with picom:
bar {
i3bar_command i3bar -t
status_command i3status
colors {
# fully transparent text on opaque background:
statusline #ffffff00
background #000000ff
}
}
|
|
|
|
related to https://github.com/i3/i3/issues/3724
|
|
related to https://github.com/i3/i3/issues/3724
fixes https://github.com/i3/i3/issues/1966
|
|
|
|
|
|
related to https://github.com/i3/i3/issues/3724
related to https://github.com/i3/i3/pull/4288
fixes https://github.com/i3/i3/issues/3721
|
|
asciidoctor is a bit stricter in what it accepts: the leading and trailing lines
need to have the exact same number of characters, and apparently there needs to
be a blank line after the trailing delimiter line.
|
|
fixes https://github.com/i3/i3/issues/5155
|
|
|
|
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)
|
|
|
|
|
|
A feature described in i3/i3#4709
|
|
|
|
Focus output next
|
|
docs: Make more clear that an IPC socket is always created
|
|
|
|
Fixes #4575
|
|
Follow-up from #4647
|
|
Incorporating orestisfl's suggestion, and expanding a little
|
|
|
|
|
|
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
|
