When matching against custom window properties or atoms perform the
matching against all available values using logical OR if the special index
`[*]` is specified. If no index is specified, we fall-back to the first
value.
This should help when an atom has multiple values and you only want to
check against any of these — e.g. hiding windows with state `hidden`:
`--opacity-rule "0:_NET_WM_STATE@[*]:32a *= 'HIDDEN'"` — without having to
explicitly specify each index separately or when the index is not known
in advance.
Updated the manpage with examples for hidden and sticky windows.
win_update_screen needs w->widthb/heightb, which is only updated in
win_on_win_size_change
Related: #554
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
fill_win only sets the pending geometry (aka the shadow geometry) of the
window, we have to wait for it to propagate to the real geometry before
we can update the screen.
Related: #554
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Since commit 95a64acf5a, fill_win doesn't
set the window geometry anymore, so we can't use it in
handle_new_windows.
However, we don't need to add damage in handle_new_windows anyway,
damage will be added later when the MAPPED flag is handled.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Consider these 2 cases:
* A window is mapped while fading out
* A window is mapped and damaged while fading out
From the perspective of map_win_start, these 2 cases look the same. The
window will has ever_damage = true in both cases. However, map_win_start
has to distinguish between these 2 cases, because at the end of
map_win_start, window in the first case cannot have ever_damage = true,
while window in the second case should have ever_damage = true.
Currently, map_win_start always clears ever_damage in both cases
(indirectly through win_skip_fading), which causes windows in the second
case to not be rendered when they should be.
This commit move clearing of ever_damage from unmap_win_finish to
unmap_win_start, so when map_win_start sees ever_damage = true, it's
always to second case. And to make sure windows which are fading out are
still rendered, we relax the ever_damage check in paint_preprocess to
also accept windows that are fading out. (see code comment for
explanation why this is fine)
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
When a window is moved during fade-out, configure_win won't add the old
window extent to damage (because it's unmapping), but the new window
extent will be added to damage when the window is rendered. And the
window will be rendered in its new location. Thus the damage for the old
window extent is missing.
We could fix this by adding damage in configure_win for unmapping window
too. But in general we don't want to move a window while it's fading
out. So we shadow the window geometry. The shadow geometry is updated in
configure_win, and the update will only propagate to real geometry in
win_process_update_flags.
This also fix the case where a window is unmapped, moved, then mapped
all in the same render cycle. map_win_start is supposed to add the old
window extent to damage in that case, but the old window extent is
already overwritten when we reach map_win_start. The shadow geometry
fixes that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Set WIN_FLAGS_MAPPED instead, it will be handled later. Previously, we
call map_win_start because we need the geometry of the window, which is
updated in map_win_start. Now, we get the geometry in fill_win, so
map_win_start is not needed anymore.
Eliminate a case where destroy_backend could see IMAGES_STALE flags set
on windows.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
While working on this PR, I introduced a bug where shadow images for
unmapped windows aren't properly recreated after unredirect/redirect.
The shadow image is freed during unredirect, OTOH redirect only set
IMAGE_STALE flags for mapped window, thus the shadow images for unmapped
windows will be missing.
This bug is already fixed in the previous commit. But the testcase is
good to keep nonetheless.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Make unmapped window events work mostly like a mapped window, except
flags set on unmapped windows aren't processed until the window is
mapped.
Hopefully this unifies some of the code paths and reduce corner cases.
Should fix#525
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
So we can bundle this request together with other requests, making
reproducing time critical bugs easier.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
This is to allow us sending the root configure request together with
other requests. Making it easier to reproduce timing critical bugs.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
