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

Update mod list through Wait.StartWaiting #3637

Merged
merged 1 commit into from
Aug 20, 2022

Conversation

HebaruSan
Copy link
Member

@HebaruSan HebaruSan commented Aug 19, 2022

Background

Both refreshing the registry and updating the mod list use the Wait tab to log their progress, so the user can see what is happening and can tell the app hasn't frozen (see #2617).

Problems

Recently (dev builds only), if you refresh the registry in GUI, the log messages for repo update remain visible while the mod list is being refreshed. The progress tab should reset because they're separate processes.

Similarly (also dev builds only), if you use the download to cache option for a mod, we open the progress tab for the download and then refresh the mod list, which also uses the progress tab, but we jump back to the mod list in between.

Cause

In #3635 we refactored the Wait tab to clean up error handling and make its use more consistent. All of the many BackgroundWorkers were combined into one and encapsulated inside Wait. As part of this, Wait.ClearLog was made private and moved from the many places where it was called previously to Wait.StartWaiting as a way to guarantee proper state when the tab starts up.

This missed the mod list refresh because it was not using a BackgroundWorker, but rather started a background thread with await Task.Factory.StartNew. So while Wait.ClearLog() was removed from the end of repo update, it was not added to the start of mod list updating.

#3635 added a call to refresh the mod list after a download to cache but didn't remove the logic that closed it when done.

Changes

  • Now the mod list refresh is refactored to use Wait.StartWaiting, like all the other users of the progress tab. The logic for refreshing the list is still in ManageMods, but the parts that manipulate the overall window state are moved to Main.ManageMods_OnRefresh.
  • Now the post-repo refresh actions for updating the mod list are cleaned up to make sure everything is opened, cleared, and closed properly.
  • Now the download to cache logic relies on the mod list refresh to close the progress tab when done. It also clears the log.

This way, when you update the registry, the Wait tab remains active (we do not want it to flicker-jump back to and from the mod list tab) but clears itself between the two flows.

@HebaruSan HebaruSan added Bug Something is not working as intended GUI Issues affecting the interactive GUI Pull request labels Aug 19, 2022
Copy link
Member

@techman83 techman83 left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Aha, that makes sense!

@HebaruSan HebaruSan merged commit 2f3d817 into KSP-CKAN:master Aug 20, 2022
@HebaruSan HebaruSan deleted the fix/modlist-refresh branch August 20, 2022 12:30
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Bug Something is not working as intended GUI Issues affecting the interactive GUI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants