_NET_WM_STATE_FOCUSED is set on _NET_WM_STATE to indicate that the
window is focused. It must be set when the window is newly focused and
removed once the window no longer has focus.
> _NET_WM_STATE_FOCUSED indicates whether the window's decorations are
> drawn in an active state. Clients MUST regard it as a read-only hint.
> It cannot be set at map time or changed via a _NET_WM_STATE client
> message.
For example, this is used by GTK applications to show the decoration in
an active or inactive state. This change can be tested by opening a GTK
application (like evince), focusing the window and unfocusing the
window, and observing a change in the window decorations.
Fixes#2273
Issue #3049 describes a case where terminating i3 by means of SIGTERM
causes it to leak the runtime directory and all its contents. There are
multiple issues at play: first, any cleanup handlers registered via
atexit are never invoked when a signal terminates the program (see
atexit(3)). Hence, the log SHM log cleanup performed in i3_exit is not
invoked in that case. Second, compared to the shutdown path for the
'exit' command, we do not unlink the UNIX domain socket we create,
causing it to be leaked as well. Third, a handler for SIGTERM is not
registered at all despite handle_signal claiming to be the handler for
all 'Term' signals.
This change addresses all three problems and results in a graceful exit
including cleanup to happen when we receive a signal with the default
action 'Term'. It addresses issue #3049.
We need to set dont_map => 1 on the sync window to prevent an endless loop.
Further, t/219-ipc-window-focus.t made assumptions about windows being named
incrementally, and that assumption is broken by the sync window opened by the
first sync_with_i3 call from open_window, so use the more reliable ->name.
I previously tried to fix the check, but could only come up with a fix which
required removing our module pre-loading, which makes the tests considerably
more expensive. Instead, let’s just remove the check.
This tool is similar to xtrace in usage in that it intercepts traffic to
the X server. The motivating feature for writing the tool is its ability
to inject prepared reply messages instead of the server’s reply. In
this particular case, we’ll inject a RRGetMonitors reply to test i3’s
RandR 1.5 code paths.
The added testcase is a noop for now, but with the code that’s lingering
in the randr15 branch, i3 does actually detect monitors as per the
injected reply:
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:618 -
RandR 1.5 available, querying monitors
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:628 -
1 RandR monitors found (timestamp 0)
2016-11-20 21:10:05 - randr.c:__randr_query_outputs:646 -
name DP3, x 0, y 0, width 3840 px, height 2160 px, width 520 mm,
height 290 mm, primary 1, automatic 1
This is preparation work for issue #1799
Orestis Floros