Allow GUI users to delete registry lockfiles #3829
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
ConsoleUI can do one thing that GUI can't:
It would be helpful if GUI users also had the option to delete the lockfile after an explanatory warning.
Problems
Main
's constructor was callingApplication.Run
, which is not good coding style; a constructor should just create the object (even under RAII), not trigger side effects such as running the entire applicationCause
Registry.Instance
before the window appears, which makes it loadregistry.json
which is around 30 MiB nowadays and causes a substantial delayChanges
Core.RegistryInUseKraken.ToString
to be shared, and the English text is edited to be clearer (one "instance" is now "CKAN process" and the other is "game folder")If you click Cancel, the manage game instances popup will appear so you can pick a different game instance (if you have any others). If you click Force, it'll try to delete the lockfile and proceed with the chosen instance.
registry.json
is loaded, and a progress bar is shown while it loadsGameInstance.Scan
call is moved from startup toUpdateModsList
with its own log message to keep the GUI responsive while it happens (since this was previously between the two progress bar sections)ShowDialog
that I was able to find, which is good practice in case we want to center the child dialogs on the parentsMain.manager
is now private and external users are switched to using the publicMain.Manager
instead, and various other members ofMain
are also made private or readonlyMain
's constructor and fromOnLoad
and moved toOnShown
, where they now occur within aWait.StartWaiting
block that shows a progress bar. The roles of these functions are now:Program.Main_
: Instantiate the main form, hide the console window, and run the applicationMain
can be loaded, such as the GUI eventsOnLoad
: Get the GUI configuration (without locking the instance!) so we can get the saved window geometry/layout before the window appearsOnShown
: Load the registry once the window appears and prompt the user for various thingsMain.tabController
andMain.Instance
are now marked with the[Obsolete]
attribute to generate code style warnings, and theMain*.cs
file now all have#pragma warning disable 0618
to suppress the warning when used by the same classThis will generally make GUI better behaved, since it will appear very soon after launch and tell the user what it's doing. And if the lockfile exists, users will have the option to delete it.
Fixes #3558.
Deferred to later
We should also show a progress bar when the user changes instances via the manage game instances popup. I looked into that and it was more complicated than I could manage at this point due to conflicting usages of the progress bar tab.