feat(animation): bring in changes from #597 #685
Conversation
LGUG2Z
force-pushed
the
feature/animated-move
branch
2 times, most recently
from
4a8f15a
to
b6dde25
Compare
raggi
force-pushed
the
feature/animated-move
branch
2 times, most recently
from
2b32c12
to
e618079
Compare
LGUG2Z
force-pushed
the
feature/animated-move
branch
3 times, most recently
from
437aaed
to
cb35eeb
Compare
|
Hi, @LGUG2Z - I understand you must be filled with work around other stuff, was just wondering on the progress with this? Please let me know if you need some help with it and I'll be happy to help wherever possible. Animations in Komorebi would be great to have! 🎉 Thanks for the work, @raggi and @LGUG2Z 🚀 |
|
The main challenge we've seen in testing is that the animations cause chrome & cef windows to render in the wrong place - they start to render outside of their client rect (which isn't visible). This is sort of a chrome bug, but one that the animations robustly trigger. I was experimenting with some other ways to do some of the actions that Komorebi takes recently, and they seem to work ok on Windows 11 so far, and might help with this problem - specifically avoiding attaching external input handler threads to the processes during window moves and focus events - but this relies on behavior we're not supposed to be allowed to do - lots of testing required. |
LGUG2Z
force-pushed
the
master
branch
3 times, most recently
from
11675ef
to
6fe4661
Compare
LGUG2Z
force-pushed
the
feature/animated-move
branch
5 times, most recently
from
71c6569
to
836cf66
Compare
|
@raggi would we have to wait for this chrome bug to be fixed before getting this pr merged? if yes, does it affect only google chrome or any other derivatives like edge and vscode, discord, etc ? I cant wait for komorebi to have animations just like on hyprland, it's the last missing piece of software I needed to make my workflow on windows same as on linux :) |
|
This will probably be released as an "experimental" option (ie. you may have to do a hard restart of apps impacted by bugs and lose data if you can't save beforehand) in v0.1.26; hopefully someone will want to stabilize it enough that they'll drive themselves crazy finding a way to fix these bugs on our end vs. waiting for Electron apps to have this fixed via Chromium. 😅 |
LGUG2Z
force-pushed
the
feature/animated-move
branch
6 times, most recently
from
306513f
to
9af834f
Compare
This commit contains all the changes of #597 to make it easier to rebase with the latest changes on master post-v0.1.21. fix(animation): Fixed cancelling logic (57e9b2f) Added static animation state manager for tracking "in_progress" and "is_cancelled" states. The idea is not to have states in Animation struct but to keep them in HashMap<hwnd, AnimationState> behind reference (Arc<Mutex<>>). So we each animation frame we have access to state and can cancel animation if we have to. Need review and testings refactor(animation): avoid unwrap (fa6d5bb) fix(animation): Move cancel call to Animation struct (306513f) Only focused window was cancelling its animation because we call cancel in window::set_position and waiting for its cancelling. And because we waiting for cancelling second window is still moving. Second window will stop moving only after the first window. So I moved `cancel` call to Animation struct so its happening in its own thread and doesn't block others animation moves and cancels.
LGUG2Z
force-pushed
the
feature/animated-move
branch
from
9af834f
to
eeee1c8
Compare
LGUG2Z
force-pushed
the
master
branch
5 times, most recently
from
0c842e4
to
05af7ce
Compare
This commit contains all the changes of #597 to make it easier to rebase with the latest changes on master post-v0.1.21.