This option accepts a list of patterns and overrides the corner radii of
matching windows
Authored-by: oofsauce <alanpanayotov@gmail.com>
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
there are two x extensions for working with monitors (especially
multiple): xinerama and randr. xinerama is old, feature-poor and in
general isn't used anymore compared to the randr: new, feature-rich and
widely-used. for some reason we were using both of them, so let's drop
xinerama to keep things simple, clean and small. and to be modern.
the drop was done in three steps:
* first step was to replace all the xinerama-based code with the
randr-based one and to replace or remove all the xinerama mentions;
* second step was to replace the xinerama's terminology with the
randr's one. xinerama was referring only to the word "screen", while
randr refers to multiple words and i think the word "monitor" is the
most suitable for us and, hopefully, clear both to a contributor and
to an end user;
* third step was to refactor the new randr-based code if needed and to
address related todo's (mostly about moving related functions
elsewhere).
all the steps were done well except addressing a leftover todo about
moving the win_update_monitor function to the x.c which wasn't done.
the xinerama-shadow-crop option was renamed to crop-shadow-to-monitor,
but it's previous name is still accepted, has effect and the
deprecation message is printed to preserve backwards-compatibility.
With rounded corners, X11 native border and blur enabled, left and
bottom 2*border_width pixels were not blurred, since mask did not
include border_width, only content width and height.
Create mask image with dimensions that include border width.
Signed-off-by: Evgeniy Baskov <j-basevgser@yandex.ru>
destroy_win_finish doesn't call win_release_images to free the images,
so we need to add a release_mask call there.
Related: #892
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Transparent clipping interacts poorly with programs whose transparent
interface elements must show windows below them for functionality,
for example screenshot utilities.
This is used to create image masks that can be used to mask out
`compose` regions. For example, this can be used to mask out window body
so shadow won't be painted on them.
This could be more efficient than using rectangular regions for masking,
when there are a large number of rectangles; or more flexible, in the
case of window with rounded corners.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
There were a few improper uses of %ld for 64 bit numbers, as well as
some other 32 bit related warnings that I've fixed.
Signed-off-by: ktprograms <ktprograms@gmail.com>
Added the new `clip-shadow-above` configuration and wintype option.
These allow the user to select windows to clip from the shadow region of
other windows, i.e. don't paint shadows on top of them.
This should provide a more useful and userfriendly alternative to the
deprecated `shadow-exclude-reg` option — especially for docks and bars.
Use window geometry (width, height) including border-width as the base
for frame region calculation with `_NET_FRAME_EXTENTS`, instead of
including the extents themselves.
Fixes issues where the frame would get incorrectly blurred *outside* the
window area.
fixes: #413#590
related: fb3305fb9b
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>
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>
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>
When the screen is unredirected, no window have a shadow image. So the
assertions in win_set_shadow don't hold. But in that case, we don't want
to add damages anyway. So we put them behind a check of whether the screen
is redirected.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Downstream code expect wid_get_text_prop to return at least 1 string.
However wid_get_text_prop would return 0 strings when the property is
set to an empty string.
Fixes: dc37370a66
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Clear both STALE flags (`IMAGES_STALE = PIXMAP_STALE | SHADOW_STALE`)
when destroying windows (see f493447b33).
Clearing `SHADOW_STALE` as well should eliminate the recreation of a shadow
image for a window currently being destroyed which will cause the
rendering to fail because we can't properly update the flags anymore.
Should fix: #394
Of course, we still use GLX, so we can't completely remove Xlib yet. But
this removes all Xlib uses outside of the backends.
This drops support for COMPOUND_TEXT Xorg strings, so people how wants
multilingual support has to use UTF8, which should be fine since most of
the applications support that.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
If a window receives multiple configure notifies in between 2 frames, we
add all the in between positions into damage, when we really just need
the starting and the end position.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
So we don't need to call c2_match every frame something is fading. Also
saves us from some out-of-critical-section X server queries.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Previously, when some explicitly checked property (e.g.
_NET_WM_WINDOW_OPACITY) changed, it won't trigger a
win_on_factor_change, and the rules will not be re-evaluated. Because
that property stale flag will be cleared after we explicitly check the
property, so it won't be detected as a tracked property change.
Here, we instead set WIN_FLAGS_FACTOR_CHANGED directly when a tracked
property changed.
Fixes: f3ff7eff8c
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
Part of the configure notify handling which requires querying the X
server, has been moved into the X critical section.
Signed-off-by: Yuxuan Shui <yshuiv7@gmail.com>
