This is achieved by retaining the IPC connection which is sending the restart
command across the restart.
This is the cleaner fix for https://github.com/i3/go-i3/issues/3fixes#3565
This change only affects clients that are subscribed to events, which
should be the main cause of our problems.
In the common case (no buffered data) the behaviour doesn't change at
all: the message is sent directly, no ev_io / ev_timeout callback is
enabled. Once a write to a client's socket is not completed fully
(returns with EAGAIN error), we put the message in the tail of a queue
and init an ev_io callback and a corresponding timer. If the timer is
triggered first, the socket is closed and the client connection is
removed. If the socket becomes writeable before the timeout we either
reset the timer if we couldn't push all the buffered data or completely
remove it if everything was pushed.
We could also replace ipc_send_message() for all client connections in
i3, not just those subscribed to events.
Furthermore, we could limit the amount of messages stored and increase
the timeout (or use multiple timeouts): eg it's ok if a client is not
reading for 10 seconds and we are only holding 5KB of messages for them
but it is not ok if they are inactive for 5 seconds and we have 30MB of
messages held.
Closes#2999Closes#2539
Sending the sync command via IPC ensures pending IPC messages are handled by i3
before the sync response is read. This is rarely useful for direct IPC
connections to i3, but becomes useful when synchronizing with i3bar, which might
have pending IPC messages in response to button clicks.
All other message types are verbs, only our first-ever message COMMAND wasn’t.
While we’re here, also change the message type dictionary into a table with
clickable links to the corresponding reply type.
Authors of downstream IPC libraries are encouraged to keep the old name around
so as to not break existing code, but mark it as deprecated.
The possible values "rename", "reload" and "restored" of the property
'change' from the workspace event were missing. Because no events of
those types contain an old workspace, this was trivial.
This event is triggered when the connection to the ipc is about to
shutdown because of a user action such as with a `restart` or `exit`
command. The `change` field indicates why the ipc is shutting down. It
can be either "restart" or "exit".
fixes#2318
This introduces the flag "--pango" on the mode config directive to
explicitly enable pango markup for mode names. Not setting this will
cause the mode name to be rendered as is.
This fixes a regression in 4.11 where mode names containing characters
such as '<' would break user's configs as they didn't escape these
characters.
fixes#1992
fixes#1835
This commit improves the translation of keysyms to keycodes by loading
keymaps using libxkbcommon-x11 and using libxkbcommon for figuring out
the keymap, depending on each keybinding’s modifiers. This way, the
upper layers of complex layouts are now usable with i3’s bindsym
directive, such as de_neo’s layer 3 and higher.
Furthermore, the commit generalizes the handling of different XKB
groups. We formerly had support only for two separate groups, the
default group 1, and group 2. While Mode_switch is only one way to
switch to group 2, we called the binding option Mode_switch. With this
commit, the new names Group1, Group2 (an alias for Mode_switch), Group3
and Group4 are introduced for configuring bindings. This is only useful
for advanced keyboard layouts, such as people loading two keyboard
layouts and switching between them (us, ru seems to be a popular
combination).
When grabbing keys, one can only specify the modifier mask, but not an
XKB state mask (or value), so we still dynamically unbind and re-bind
keys whenever the XKB group changes.
The commit was manually tested using the following i3 config:
bindsym Group4+n nop heya from group 4
bindsym Group3+n nop heya from group 3
bindsym Group2+n nop heya from group 2
bindsym n nop heya
bindsym shift+N nop explicit shift binding
bindsym shift+r nop implicit shift binding
bindcode Group2+38 nop fallback overwritten in group 2 only
bindcode 38 nop fallback
…with the following layout:
setxkbmap -layout "us,ua,ru,de" -variant ",winkeys,,neo" \
-option "grp:shift_caps_toggle,grp_led:scroll" \
-model pc104 -rules evdev
By default (xkb group 1, us layout), pressing “n” will result in the
“heya” message appearing. Pressing “a” will result in the “fallback”
message appearing. “j” is not triggered.
By pressing Shift+CapsLock you switch to the next group (xkb group 2, ua
layout). Pressing “a” will result in the “fallback overwritten in group
2 only” message, pressing “n” will still result in “heya”. “j” is not
triggered.
In the next group (xkb group 3, ru layout), pressing “a” will result in
the “fallback” message again, pressing “n” will result in “heya”,
“j” is not triggered.
In the last group (xkb group 4, de_neo layout), pressing “a” will still
result in “fallback”, pressing “n” will result in “heya”, pressing “j”
will result in “heya from group 4”.
Pressing shift+n results in “explicit shift binding”, pressing shift+r
results in “implicit shift binding”. This ensures that keysym
translation falls back to looking at non-shift keys (“r” can be used
instead of ”R”) and that the order of keybindings doesn’t play a role
(“bindsym n” does not override “bindsym shift+n”, even though it’s
specified earlier in the config).
The fallback behavior ensures use-cases such as ticket #1775 are still
covered.
Only binding keys when the X server is in the corresponding XKB group
ensures use-cases such as ticket #585 are still covered.
Send the affected workspace in the "current" property for each workspace
event for any type of workspace event that affects a particular
workspace.
fixes#1411
When dumping a binding, as is done during the binding event, check
symbol for NULL. If it is, dump json null. This prevents a crash when
running a binding that was configured with bindcode.
fixes#1379
The binding event will be triggered when a binding is run as a result of
some a user action. The binding event has the following properties:
change: (str) Currently this will only be "run" but may be expanded in
the future. Included for consistency with other events.
binding: (map) the serialized binding
The "binding" member will have these properties:
input_type: (str) either "keyboard" or "mouse"
input_code: (int) the xcb keycode of the keyboard binding if it was
provided or the mouse button if it is a mouse binding.
symbol: (str) the string representation of the input code
command: (str) the bound command
mods: (list of str) a list of the modifiers that were pressed as string
symbols
fixes#1210
When a named workspace (i.e., a workspace that has a name that does not
begin with text that can be parsed as an integer greater than or equal
to zero) is represented by the ipc as a workspace json object such as
can be queried with `i3-msg -t get_workspaces`, set the num property to
-1 instead of json null.
This is for convenience of ipc consumers using type-constrained
languages such as C which have difficulty cleanly expressing nullable
integers.
fixes#1368
The fullscreen_mode event is a window with the "change" property set to
"fullscreen_mode". This event should be emitted whenever a window enters
or exits fullscreen mode.
This event can be used to turn off dpms off when a window is fullscreen
or display the fullscreen container name in the status line for
instance.
Send all the options in the bar block on the barconfig_update event.
This will eventually allow for dynamically updating bar colors with the
`reload` command.
Iskustvo