We detach the client window from its frame when it's destroyed, so later
a new window can be attached to that frame. But turns out that's not
enough.
When i3 restarts, it attaches a placeholder window to the frame, then
the real window, and only after that, it will destroy the placeholder.
The real window will fail to attach as the frame already has a client.
When the placeholder is destroyed, we have to call recheck client to
pick up the real window that failed to attach previously.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Basically, don't ignore the reparent notify if the window is already a
client window. We already unmark it from its previous frame, so this
commit make sure it gets marked with its new frame.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
We do nothing when a non-wm-frame window is destroyed. This will cause
trouble if a wm-frame window is reused (i.e. its child is destroyed then
a new child is reparented to it), because we didn't clear client_win.
So this commit adds a call to win_unmark_client for that case.
Related: #299
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously, root ConfigureNotify is handled immediately, by resetting
the backend, which in turn releases all the window images. This puts all
the windows into a state where they don't have images attached, which
they really should be in when the screen is redirected.
(To expand a little, a window without images should only exist if:
* It's an unmanaged window.
* Screen is unredirected.)
Normally, this kind of window could be fine, as the next render phase
will re-acquire images for them. However, if a window in this state is
destroyed with fading enabled, then the render phase won't try to
acquire images for it, causing it to go into the main rendering function
without images attached, and trigger an assertion.
This commit delays the handling of root ConfigureNotify until the render
phase. This way, the images will be immediately re-acquired after they
are released, thus prevent this problem from happening.
Also adds a testcase for this.
Fixes#357
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Unredirect the screen when some window sets _NET_WM_BYPASS_COMPOSITOR
to 1, but ignore the case where some window requests the screen to be
redirected by setting _NET_WM_BYPASS_COMPOSITOR to 2.
Closes#267
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
leftovers:
1) config file path. Has to implement compatibility functionalities before
we can change it.
2) links in man pages. Has to migrate the repo first.
3) _COMPTON_SHADOW, it has become a defacto standard, so we have to keep
supporting it.
4) dbus names, undecided whether we should/could change it.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
A quick search on GitHub showing the _COMPTON_SHADOW is actively being
used (most noteably, by polybar). It is not a difficult thing to support,
and it doesn't have that much runtime overhead. So remove the option
that guards this feature, make it enabled by default.
(Side note, I saw lots of people putting this option in their config
files, but this is actually a command line only option.)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Firstly, this breaks the assumption that when we redirect the screen,
all window is either mapped or unmapped, causing a assertion failure.
Secondly, if transition window into fading when the screen is not
redirected, the fading will not progress until the screen is redirected,
probably not the desired result.
Fixes#246
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
win_get_name _updates_ the name of the window by querying the X server,
thus potentially changes the behaviour of the compositor when logging is
turned on (e.g. we could fail to detect window name changes, because the
name was blindly updated in a logging call without handling the name change).
We shouldn't do that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
And a window update flag for mapping the window.
Also make sure related functions consider the case where the given window
has pending updates.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
rename map_win, unmap_win, destroy_win to map_win_start,
unmap_win_start, destroy_win_start respectively. To clarify their
intended functions. Also rename the corresponding finish_* functions to
*_finish so they are consistent.
Also some very minor code clean ups.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of doing both unmapping and destroying in the same function,
since that complicates the logic.
Also since now destroy_win handles both the managed and unmanaged cases,
remove destroy_unmanage_win function.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Instead of pointer to pointer. The two level of pointers were used to
inform the caller the window has been destroyed (pointer set to NULL).
Now, destruction of windows are now signaled by the return value, which
is marked `must_use`.
Problem with taking pointer to pointer is that they tends to pollute the
function signatures a little bit. And we are not using it well anyways.
A lot of the callers passes pointers to local variables to those
functions, so the information about window destruction doesn't actually
bubble up. So, we switch to use just one level of pointers instead.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Only render blur with transparency when window is fading in/out.
Otherwise, a window with a set opacity will always have a completely
blurred background.
Fixes#198
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Delay focus updates until critical section. Rational is that focus
events might arrive when the focused window hasn't been managed by
compton, result in that that window not being focused.
This commit makes compton mark focus update events, and only update
focus in critical section, after we managed all the new windows.
Fixes#177
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Remove more unused stuff.
Also removed session::xinerama_scrs, since all the information we need
is covered by xinerama_scr_regs. Convert uses of xinerama_scrs to use
xinerama_scr_regs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
It used to be unmap when we receive its MapNotify, but now since we discard
events received before we grab X server, that event it lost. But it
turns out we can just unmap it when it's first created, no need to wait
for the MapNotify.
Partially fix#160
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When a window is reparented to the same parent again, we should just
move it to the top of the stack, instead of add it again.
Also a slight refactor restack_win.
Fixes#164
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Create a "critical section" in draw_callback by grabbing the X server.
Delay the managing of newly created windows until we enter the cricial section.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Currently compton handles window creation event by immediately query all
the information it needs and create a window struct with that
information. However, this is prone to race conditions.
In the future, we want to react to window creation event by creating a
placeholder in the window stack, and only query window information in a
critical section where the X server is grabbed by us.
This commit split struct win into two struct, one as placeholder, the
other for holding actual window information.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Yuxuan Shui