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.
- Make sure to place the description of the packet before the
description of the payload.
- Describe the relationship of messages and replies.
- Add note on pipelining.
I was confused by the previous state of the docs since I imagined that
there is still a race possible. Thus, the images are updated to
explicitly include the IPC reply from i3 (since that is an important
synchronisation component). I also tried to clarify some of the text.
Fixes: https://github.com/i3/i3/issues/4365
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently i3bar click events provide x and y coordinates relative to all monitors.
I've added coordinates relative to the current output.
+-----------+-----------+
| | i3bar |
| +-----------+
| HDMI-0 | DP-0 |
| 1920x1080 | 2560x1080 |
+-----------+-----------+
When you click in the top right corner of the DP-0,
i3bar will provide something like this:
{
"x": 4480,
"y": 10,
"output_x": 2560,
"output_y": 10,
}
This is useful for creating a rofi menu or something else.
rofi -show run -location 1 -xoffset ${I3_OUTPUT_X} -yoffset ${I3_OUTPUT_Y}