Fixes#3595
Like the issue mentions:
> instead of the newly created workspace (not referenced by variable
> here) the `"init"` event is fired with the current workspace (`ws`).
Plus, there was another issue where duplicate workspace init events
where being sent because of workspace_get().
304-ipc-workspace-init.t: Subtest "move workspace to output" fails with
current next.
Fixes#3631
No event was being sent here:
2d6e09a66a/src/randr.c (L487)
533-randr15.t: I confirmed that SKIP still works if the xrandr command
fails.
Added test fails with current next.
- __lsan_do_leak_check() will terminate the process, so move it to the
end of the function.
- ev_loop_destroy() must be called after ipc_shutdown() because the
latter calls ev_ functions.
Fixes#3599
I was able to reproduce #3579 in Linux by running:
`sudo sysctl net.core.wmem_default=10000`
If a subscription message was too big to be sent at once, it was
possible to break a client by sending a reply to an other message sent
by the client. Eg:
- Write 8192 out of 11612 bytes of a workspace event.
- Blockingly write the reply to a workspace change message.
- Write the rest 3420 bytes of the workspace event.
This commit fixes this by utilizing the ipc queue for all types of
writes.
ipc_receive_message can only be called from a callback started in
ipc_new_client. This callback uses the same file descriptor with the
client also created in ipc_new_client. When the client is deleted, the
read callback is now also stopped. Thus, we can assume that whenever
ipc_receive_message is called, the corresponding client should still
exist.
- ipc_client now contains pointers to both write and read watchers. When
freed, a client will stop both of them.
- IPC_HANDLERs now work with ipc_clients instead of fds.
Fixes#3579.
errx() already appends \n internally. "\n" in the error message will
result in a blank line after the message. die() is just a wrapper around
errx() so it receives the same treatment.
After 204eefc. Alternative fix:
diff --git a/src/floating.c b/src/floating.c
index f5c61782..6dd79668 100644
--- a/src/floating.c
+++ b/src/floating.c
@@ -954,7 +954,7 @@ bool floating_reposition(Con *con, Rect newrect) {
con->scratchpad_state = SCRATCHPAD_CHANGED;
/* Workspace change will already result in a tree_render. */
- if (!reassigned) {
+ if (!reassigned && workspace_is_visible(con_get_workspace(con))) {
render_con(con);
x_push_node(con);
}
but I don't think that the extra complexity is worth it.
Change in handlers.c because of d2d6d6e0 where the bug also appears.
Fixes#3567
The userguide contained a commented-out section for marks, which
included the line:
> TODO: make i3-input replace %s
The line was added in a26a11c609 (May
2011), at which point i3-input did not have a -F switch. The switch
was added only in 1737a78fcd (September
2011), but the documentation was never updated to enable the
commented-out examples.
- Explicitly document --replace, which was previously only mentioned
in the command syntax.
- Improve wording: "a window can only have one mark" is slightly
misleading because it appears to describe the limitation as a
property of the model, whereas this actually pertains the mark
command.
on_remove_child calls tree_close_internal which calls tree_render and
the tree is in an invalid state if con->parent still points to the old
parent.
Fixes#3556
Using the wrong X11 connection breaks the libev event handling model:
xcb_flush() must be called immediately before handing control to libev.
Before this fix:
1. xcb_prepare_cb would read and flush conn
2. restore_xcb_prepare_cb would read and flush restore_conn,
BUT also inadvertantly call xcb_flush(conn), resulting in new
events being filled into the XCB event queue
3. libev waits for new events
4. after 1 minute, libev times out and the events are processed
Diagnosed using strace on testcases/complete-run.pl.
related to commit 0d8b6714e3
related to #3510
Basic idea: if the window has a shape, set the parent container shape as
the union of the window shape and the shape of the frame borders.
Co-authored-by: Uli Schlachter <psychon@znc.in>
Michael Stapelberg