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)
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
This criterion matches all open windows, as a more readable (and
correct) version of the 'class=".*"' criterion (more correct because
it'll also match windows which don't have WM_CLASS set yet).
This feature defaults to off, and can be turned on for individual windows,
or (with for_window) for all new windows. See the userguide change.
This commit is partially based on work by:
• Marius Muja
• mickael9
• Esteve Varela Colominas
• Bernardo Menicagli
The implementation uses wordexp(3) just like sway:
https://github.com/i3/i3/issues/1197#issuecomment-226844106
Thanks to jajm for their implementation at
bb55709d0a
This required refactoring the config parser to be re-entrant
(no more global state) and to return an error instead of dying.
In case a file cannot be opened, i3 reports an error but proceeds with the
remaining configuration.
Key bindings can be overwritten or removed using the new --remove flag of the
bindsym/bindcode directive.
All files that were successfully included are displayed in i3 --moreversion.
One caveat is i3 config file variable expansion, see the note in the userguide.
fixes#4192
This helps write correct descriptions of the JSON schema for strongly
typed languages that support deserializing to native types (and
require a different type for null).
These seemed to be inconsistently specified.
Particularly, the "SYNC" message payload was not described anywhere.
Even when the payload is empty, it is helpful to specify that
explicitly, as it prevents the reader from having to guess whether if
it's really empty, or otherwise somehow implicitly obvious.
The "Reply format" section is now "Messages and replies", and covers
both the reply format and the format of sent messages.
