Add Animation and Sound / Fix Last Executed Position

[onesounds]

bandicam.2021-11-12.11-07-08-371.mp4

• Add Slide up animation when open flow
• Fix Remember Last launch position when Relaunch Flow
  • There is a problem that the Y position is mysteriously changed, but it was revised to the code below. (I don't know for sure why it works.) I think Size OfChanged is the reason. It is saved in the settings based on where the program was terminated. I think it would be safer to save it whenever the location changes.
  • Refs
  • Wox-launcher/Wox@2af7514
  • Position Reset .启动/查询 后位置自动恢复到起始位置 -v1.3.183 Wox-launcher/Wox#823
• On/Off Option
• Sound Effect

ETC

• Fix Blink Animation when close setting window
• Change 'Open' tray menu to toggle
• Change Hide/Open Code with out using visibility base
• Reduce Height of setting window Change Setting window Height to responsible (80% of Screen Height)

[onesounds]

If we apply this pr, we should all use this code later. Visibility should not be used directly as possible, but should be toss to animation code.

[jjw24]

when started up, the search bar's position is moved to the right, and then readjusted after one deactivate-reactivate

[onesounds]

As you know, in this case, there should be a delay regardless of animation because the query should be erased.

[onesounds]

If you toggle continuously very quickly with the animation setting on, there are cases where the frame is still wrong. (Blinking momentarily when the flow is turned on in this state.) It needs to be very fast, I think it's an unusual situation, and I think it's okay to leave it as it is.

Overall, since the delay time was reduced, the response thought to be a little slow would have decreased.

[jjw24]

looks like the extra hide is gone when switching three times quickly.

the old problem where it flickers when Settings window is opened or closed is back.

[onesounds]

looks like the extra hide is gone when switching three times quickly.

the old problem where it flickers when Settings window is opened or closed is back.

This problem occurs when the window is opened in the "animation off state" and changed back to the "animation on state". This is because when the window is turned on in the animation off state, there is no delay, so it remains in the opacity 1 state. In other words, problems arise because it is not initialized when closing the window.

Therefore, the window hiding during ondeactivation was modified to add a delay regardless of animation setting.

[jjw24]

is this change intended for this pr?

[onesounds]

yeah, for Icon animation.

[jjw24]

The search icon seems to just jump up a little as if to reposition itself to the right height. Is this the same case for you?

[onesounds]

Is there anything else you want me to fix?
There is still an issue that flashes when setting is changed in a specific situation, but I don't think there is a problem with actual use. I think it's a problem that you can just go. This part is difficult to fix.

[jjw24]

i am still doing some testing with it and making minor updates, will push up later.

[jjw24]

what is WinToggleStatus used for exactly? Seems to function the same as Visibility check

[onesounds]

what is WinToggleStatus used for exactly? Seems to function the same as Visibility check

Logically, there's no problem. but there was a blinking problem. I added a variable for toggle separately because I saw an advice not to use visibility as a trigger when using this kind of animation. and I felt that the data was modulated because there were codes everywhere that changed visibility.

I tested it once in the middle of this PR, and if all the visibility code is changed to opacity = 0 or 1, it will be updated even if it is not visible on the screen, so it will work even after removing all the delays, and logically, it will all work properly if I use trigger base visibility. In this method, a window exists in alt+tab, and consideration was canceled due to the problem of receiving input even if it was not visible on the screen. If we solve the alt tab and focus problem, I think this method is also good.

In principle, if the UI is updated even in the hidden/visible state, the animation can be initialized, the delay can be eliminated, and all blinking problems disappear. It's the same issue as lastemptyquery. These codes were created because this method was not available. To solve a number of problems existing in this code, a method of updating the UI even if a window is hidden on the screen must be implemented first. Things such as background worker, dispatcher, and invoke are needed. This plan is one of the solutions already proposed in the lastemptyquery and has not been considered because it cannot be implemented.

[jjw24]

I just did some refinements based on extensive testing, mainly around delay and show/hide calls. In some extreme scenarios as you mentioned as well, there are still flickering, but those edge cases aside I think this now is good.

[jjw24]

Some points as a result of testing this change I want to record below for future reference incase needed:

• MainWindowOpacity is used to stop from mainwindow slow flickering when used with animation

• Task.Delay(100) is used to stop from mainwindow fast flickering when used with animation

• Application.Current.MainWindow.Hide(); is removed from SingletonWindowOpener class because it caused flickering when Setting window is opened

• Toggling mainwindow to show immediately after opening Setting window when animation is off triggers an extra OnDeactivated call at the end, causing the mainwindow to be hidden. The Application.Current.MainWindow.Hide() from SingletonWindowOpener was used to combat this so with it the mainwindow will actually show as intended. However using this caused flickering with animation when Settings window is opened, so it's removed.

• toggling very quickly on off mainwindow, with animation on, the Hide() is called sometimes instead of Show(), so the hide->show->hide->show sequence is not exactly honoured. toggling slower will not have this issue, neither does doing it without animation. This is likely due to the Task.Delay(100).