Description
It would be cool if we could animate visibility changes made by filter, including filter reset: windows leaving the filtered set fade out; newly visible windows fade in. I suppose we could reuse fade_out and fade_in to accomplish this.
Scope
I did a brief lookover of the codebase to see how difficult this would be to implement. My estimate is that 7-10 files would be touched:
- Filter transition state in
root.h / root.c
- Capturing before/after filter membership in
layout.c.
- Keeping outgoing workspace/container scene trees enabled during fade-out, then disabling them after completion in
transaction.c.
- A separate filter-opacity multiplier so fades do not overwrite the existing opacity command’s alpha state (
opacity.c).
- Some unit tests/documentation. IIRC, I don't think there exists a direct rendered opacity assertion for checking if a given window is transparent or not.
This might be a moderately invasive request depending on how it's implemented. I just think it'd be neat if the filter feature had an animation to go with it, as I would use it for things like a shutdown/lock/unlock animation sequence B)
Description
It would be cool if we could animate visibility changes made by
filter, includingfilter reset: windows leaving the filtered set fade out; newly visible windows fade in. I suppose we could reusefade_outandfade_into accomplish this.Scope
I did a brief lookover of the codebase to see how difficult this would be to implement. My estimate is that 7-10 files would be touched:
root.h/root.clayout.c.transaction.c.opacity.c).This might be a moderately invasive request depending on how it's implemented. I just think it'd be neat if the
filterfeature had an animation to go with it, as I would use it for things like a shutdown/lock/unlock animation sequence B)