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.
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).
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.
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
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
}
}
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#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)
Malix