feat(animations): add window move animations

[LGUG2Z]

No description provided.

[thearturca]

@LGUG2Z Hi there. I was watching your videos and came up with idea to animate border too. The idea is to shrink border in size to be smaller than current focused window and then raise it up in new focused window position. So we have 2 part of transition - out and in.

I did some progress on that but get stuck on several issue.

Border demo (WIP)

border-animation.mp4

Issues

1. I'm confused by this line. Why does it subtract left from right?
   Because of that I cant get right calculations for border animations target postions.
   In case of moving border from left window to top-right window (check video above) I'm getting window rect where left is bigger than right. And when we calculate in_start_rect, its way left than the target rect. But border end up positioned in right place. I dont get it 🤷

// window rect
[komorebi\src\border.rs:197] window_rect = Rect {
    left: 961,
    top: 58,
    right: 948,
    bottom: 501,
}
// current border rect. Before transition
[komorebi\src\border.rs:198] prev_border_rect = Rect {
    left: 14,
    top: 54,
    right: 942,
    bottom: 1012,
}
// calculating center point in current focused window
[komorebi\src\border.rs:199] out_new_center_point_top = 479
[komorebi\src\border.rs:200] out_new_center_point_left = 464
// calculated rect for first part of transition. It should be smaller than current window rect by 50%
[komorebi\src\border.rs:201] out_new_rect = Rect {
    left: 239,
    top: 266,
    right: 703,
    bottom: 745,
}
// calculating center point in new focused window
[komorebi\src\border.rs:202] in_start_center_point_top = 224
[komorebi\src\border.rs:203] in_start_center_point_left = -11
// calculated rect for second part of transition. It should be smaller than target rect by 50%
[komorebi\src\border.rs:204] in_start_rect = Rect {
    left: 477,
    top: 139,
    right: 465,
    bottom: 363,
}
// target border rect. After transition
[komorebi\src\border.rs:205] rect = Rect {
    left: 964,
    top: 54,
    right: 942,
    bottom: 502,
}

2. When I change focus by mouse click update focus event fires only one time and border transition works normally. But when I change focus via whkd (alt+direction) or when move windows (alt+shift+direction), Komorebi get two events at the same time and transitions brokes. Need to debug that to understand whats going on

I dont know should I dig further or give up with that idea because it's produces more bugs and issue? 😺

[LGUG2Z]

I'm confused by this line. Why does it subtract left from right?

This is a pretty old piece of code and I don't quite remember at this point 😅 However, if you remove the transactions the border goes absolutely way too wide to the right and to the bottom lol.

I think the doubled events relates to the focus() being triggered by komorebic focus here: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window_manager.rs#L1203

Which then triggers another focus() here: https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/process_event.rs#L218

Maybe we can add another WindowManagerEvent to be called in the first instance, which would trigger the handler for this in the process_event.rs file? 🤔

[LGUG2Z]

Can you try making this change in window_manager.rs and see if the events are still doubled for you?

        // self.focused_window_mut()?.focus(self.mouse_follows_focus)?;

        WINEVENT_CALLBACK_CHANNEL
            .lock()
            .0
            .send(WindowManagerEvent::UpdateFocusedWindowBorder(
                *self.focused_window()?,
            ))?;

[LGUG2Z]

https://github.com/LGUG2Z/komorebi/blob/master/komorebi/src/window_manager.rs#L1329

I think you can also try removing this line for moves, which is the culprit for the focus_container() being called twice on MoveWindow 🤔

[LGUG2Z]

@thearturca I've been noticing quite a lot of issues with the ALT key "sticking" (for lack of a better term) when using this branch; have you experienced this at all?

[thearturca]

@LGUG2Z You've missed komorebic commands. Its still Animate instead of Animation
https://github.com/LGUG2Z/komorebi/pull/597/files#diff-669eb0fce6967fea49390c1ec784c3c4df5a95f95853066d97720a33947503ccR1082-R1090

[thearturca]

Can you try making this change in window_manager.rs and see if the events are still doubled for you?

        // self.focused_window_mut()?.focus(self.mouse_follows_focus)?;

        WINEVENT_CALLBACK_CHANNEL
            .lock()
            .0
            .send(WindowManagerEvent::UpdateFocusedWindowBorder(
                *self.focused_window()?,
            ))?;

Can you try making this change in window_manager.rs and see if the events are still doubled for you?

        // self.focused_window_mut()?.focus(self.mouse_follows_focus)?;

        WINEVENT_CALLBACK_CHANNEL
            .lock()
            .0
            .send(WindowManagerEvent::UpdateFocusedWindowBorder(
                *self.focused_window()?,
            ))?;

I've tried that but it didnt help. Still getting 3 calls of border.set_position(...). From both move window and change focus via whkd. Gonna dig through that later.

I have some news about first issue that mentioned here. From in Rect struct is converting top, left, bottom, right to top, left, height, width. And WndowsApi::set_pos(...) takes top, left, height, width. Maybe I cant get right calculations for border now. But Rect struct has invalid properties names. It should be top, left, height, width instead of top, left, bottom, right. That tricked me 🙂

[LGUG2Z]

With all of the latest changes from master merged in I think that the animations code for windows seems stable enough to merge into the master branch. I do sometimes get issues with how the windows are drawn, particularly web view windows, but it's quite rare and I think that we can be explicit about this possibility in the documentation if users decide to enable animations.

What do you think about getting this work merged and then opening a separate PR for border animations?

[thearturca]

With all of the latest changes from master merged in I think that the animations code for windows seems stable enough to merge into the master branch. I do sometimes get issues with how the windows are drawn, particularly web view windows, but it's quite rare and I think that we can be explicit about this possibility in the documentation if users decide to enable animations.

What do you think about getting this work merged and then opening a separate PR for border animations?

@LGUG2Z
Sorry for delay in replying to that PR
I think we still have to implement animation canceling or other way to prevent this bug:

chrome_bug.mp4

Its occurs when komorebi perform two animation in different direction. Maybe we should add some WIN32 flag to position method idk.
Imo its critical issue for now. Because you have to restart chrome or just dont use it 🙂

[mmikeww]

Its occurs when komorebi perform two animation in different direction

If you are moving two+ windows simultaneously, you could look into using DeferWindowPos which should be faster/smoother

[LGUG2Z]

Continuing this in #685 - rebasing with all of the commits was a nightmare so I just took the changes onto a new branch with a single commit so I only had to resolve conflicts once.