`fade_in` and `fade_out` animations for `scrollmsg filter`

[eghere]

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)

[eghere]

Other things I forgot to mention in the description but would likely be edge cases in implementation:

• Workspace/overview/fullscreen scenes
• A filter command taking place during the animation should behave like other animations (i.e., it gets canceled)
• If we set a window opacity, it should be restored when the filter is removed

[dawsers]

This is more complicated than what it seems, and would hurt performance and create some maintenance issues, so I will leave it open, but I don't see it as a feature that will happen soon.

The main problem is the filters are just functions that return whether a workspace/container need to be rendered or not, but there is no history or setup for them, just a toggle that sets the corresponding filter function. To be able to animate the opacity in/out, I would need to know what you describe as "Capturing before/after filter membership", and that would create other maintenance problems I am not sure I want to deal with for something that is just "pretty", but doesn't improve workflow.

Thank you for the idea, let's leave it open and it may happen in the future.