Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[window-state] JS api should await promise in saveWindowState #432

Closed
ahodesuka opened this issue Jun 12, 2023 · 2 comments · Fixed by #435
Closed

[window-state] JS api should await promise in saveWindowState #432

ahodesuka opened this issue Jun 12, 2023 · 2 comments · Fixed by #435
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@ahodesuka
Copy link

ahodesuka commented Jun 12, 2023

The main use case for this API, I assume, is to call saveWindowState before closing the window via appWindow.close.
In it's current state this does not work because the window is closed before the state is actually updated and saved, on my hardware at least.
The other functions in the API should probably be awaited as well.

On a side note exposing the window.update_state function through the API would allow the user to mimic what the plugin does on the onCloseRequested event, and prevent saving all window states when one window is closed.
Again this invoke call would have to be awaited in this case to work correctly.

After looking more at the plugin this would require a bit of a refactor.

This whole issue still stems from the fact that appWindow.close does not invoke the onCloseRequested event on the window. (tauri-apps/tauri#5288)

@FabianLars
Copy link
Member

Thanks for the report :)

On a side note exposing the window.update_state function through the API would allow the user to mimic what the plugin does on the onCloseRequested event, and prevent saving all window states when one window is closed.

How so (genuine question)? From what i can see, what the plugin does on close is to call save_window_state (which uses update_state internally) which is what the saveWindowState function does too.

Did you test if adding await actually fixes the issues you're having? Because from the usage of this function i've seen so far it seemed to work as-is (we should add the await anyway)

@FabianLars FabianLars added bug Something isn't working good first issue Good for newcomers labels Jun 12, 2023
@ahodesuka
Copy link
Author

How so (genuine question)? From what i can see, what the plugin does on close is to call save_window_state (which uses update_state internally) which is what the saveWindowState function does too.

It's a bit of a premature optimization, but in my case it causes 2 disk writes, one when you call the saveWindowState and another one when the plugins Exit event handler fires.

Did you test if adding await actually fixes the issues you're having? Because from the usage of this function i've seen so far it seemed to work as-is (we should add the await anyway)

Yes, albeit I didn't modify the plugin, but I mimicked what it does whilst adding an await.

amrbashir added a commit that referenced this issue Jun 13, 2023
amrbashir added a commit that referenced this issue Jun 13, 2023
amrbashir added a commit that referenced this issue Jun 13, 2023
amrbashir added a commit that referenced this issue Jun 13, 2023
* fix(window-state): correctly set decoration state if no saved state exists, fixes #421 (#424)

* fix(window-state): propagate promise (#435)

closes #432

* fix(window-state): manual default implentation (#425)

* fix(window-state): manual default implentation, closes #421

* Update lib.rs

* change file

* generated files

* fix symlinks?

---------

Co-authored-by: Fabian-Lars <fabianlars@fabianlars.de>
OrIOg pushed a commit to OrIOg/plugins-workspace that referenced this issue Jun 25, 2023
lucasfernog added a commit that referenced this issue Jul 19, 2023
Co-authored-by: Fabian-Lars <fabianlars@fabianlars.de>
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: FabianLars <fabianlars@fabianlars.de>
Co-authored-by: FabianLars <FabianLars@users.noreply.github.com>
Co-authored-by: Alexandre Dang <124160233+vdang-crabnebula@users.noreply.github.com>
Co-authored-by: Ludea <ludovicw35@hotmail.com>
Co-authored-by: Amr Bashir <amr.bashir2015@gmail.com>
Co-authored-by: Duke Jones <104690+dukejones@users.noreply.github.com>
Co-authored-by: NaokiM03 <37442712+NaokiM03@users.noreply.github.com>
Co-authored-by: Thibault <thibault_poisson@orange.fr>
Co-authored-by: github-actions[bot] <41898282+github-actions[bot]@users.noreply.github.com>
Co-authored-by: David Blythe <49919035+writeDavid@users.noreply.github.com>
Co-authored-by: Lucas Nogueira <lucas@tauri.studio>
fix(stronghold): change wrong argument name for `remove` (#422)
fix(window-state): correctly set decoration state if no saved state exists, fixes #421 (#424)
fix(stronghold): return null if there is no record (#129)
fix(window-state): propagate promise (#435)
closes #432
fix(window-state): manual default implentation (#425)
fix(window-state): manual default implentation, closes #421
fix(deps): update rust crate iota-crypto to 0.21 (#438)
fix readme example (#447)
fix: handle recursive directory correctly (#455)
fix(deps): update rust crate sqlx to 0.7. plugin-sql msrv is now 1.65 (#464)
fix(persisted-scope): separately save asset protocol patterns (#459)
fix(deps): update rust crate iota-crypto to 0.22 (#475)
fix(deps): update tauri monorepo to v1.4.0 (#482)
resolve to v15.1.0 (#489)
fix(deps): update rust crate iota-crypto to 0.23 (#495)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants