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}
