Closed Kasper24 closed 2 years ago
Of course -- the tricky bit is only going to be to think of how the syntax for that would be in the config file.
We'll probably want to do something along the lines of what is currently done with opacity-rule
, but with multiple parameters (instead of just the opacity).
I've been thinking about this. I believe we should first focus in creating good window animations (there are still a few issues that need to be solved for that), and do a PR to upstream; after that, we work on things such as this (which would be really nice to have, but aren't a part of the core of animation code), probably right on upstream.
wdyt?
This has been also implemented now, you can disable animations on window type basis all together or define different animations for them, please see this commit: https://github.com/pijulius/picom/commit/c88fc36b30efbf0aad5ffff2751f185e4b32f911
This has been also implemented now, you can disable animations on window type basis
It would be cool to use all the windows flags like we do in blur-background-exclude
for example:
blur-background-exclude = [
"window_type = 'dock'",
"window_type = 'desktop'",
"_GTK_FRAME_EXTENTS@:c",
]
I'm using AwesomeWM and have been using awestore to handle animations, but since the LUA code is single threaded I was experiencing pretty heavy stutters. I saw you mentioning your branch on some issue on the picom repo, and since moved to handling the animations via it. IIRC you talked about the ability to disable animations per window type, I'm wondering if it would be possible to expand that onto having all the options modifiable per window type. That way it would be possible to animate each widget differently (or windows).