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

Hide StatusProgress-bar if user cancels installation #2418

Closed
wants to merge 14 commits into from
Closed

Hide StatusProgress-bar if user cancels installation #2418

wants to merge 14 commits into from

Conversation

DasSkelett
Copy link
Member

Problem:
If you manually cancel the Installation process, the lower right Progress bar keeps moving.

Solution:
Reset and hides StatusProgress bar if user cancels installation.
Give a better StatusMessage too (as "Error!" is not only verry vague, it's incorrect too in this case.)

Fixes #2417

@DasSkelett
Copy link
Member Author

DasSkelett commented Apr 22, 2018

Interestingly, the GUI switches to the Modlist tab afterwards, and I have no idea why, as it shouldn't do it on errors though, and I see no code difference between handling errors and handling user cancellation regarding tab switches.
I suspect, that CKAN switches tabs on errors too (despite the code comment), but I don't know how to simulate an error to test this.

@HebaruSan HebaruSan added the GUI Issues affecting the interactive GUI label Apr 22, 2018
Copy link
Member

@HebaruSan HebaruSan left a comment

Choose a reason for hiding this comment

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

Added a few code comments. The overall approach looks reasonable to me. Nice job!

I believe the switching back to mod list happens in MainWait.cs, in CancelCurrentActionButton_Click, which calls HideWaitDialog at the end. Just mentioning that in case you want to investigate it.

@@ -390,6 +390,19 @@ private void PostInstallMods(object sender, RunWorkerCompletedEventArgs e)
RetryCurrentActionButton.Visible = false;
UpdateChangesDialog(null, installWorker);
}
else if(!result.Key && installCanceled){
Copy link
Member

Choose a reason for hiding this comment

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

We don't need to check result.Key here, because we're already in the else block of if (result.Key).

Also, can you put the curly brace on a new line? This file follows that convention currently.

RetryCurrentActionButton.Visible = true;
Util.Invoke(statusStrip1, () =>
{
StatusProgress.Value = 0;
Copy link
Member

Choose a reason for hiding this comment

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

It would be nice if we didn't have to directly manipulate specific properties of GUI objects here. Some sort of helper function to encapsulate this at a higher level.

MainWait.cs already has a partial API along those lines with ShowWaitDialog and HideWaitDialog. Maybe it should also have FailWaitDialog, which could then be called by the cancel and error blocks here? Looks like the parameters should be the messages to display.

Copy link
Member Author

Choose a reason for hiding this comment

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

HideWaitDialog already gets passed a bool success, but it's not used yet.
Either we keep this and differentiate success or we create an explicit function.

Copy link
Member

Choose a reason for hiding this comment

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

I thought the idea was to avoid hiding it, though, so the user can look at the errors.

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, as you mention it...
It would be a bit odd to have a funtion called HideWaitDialog to not hide the WaitDialog in case of an error...

HebaruSan and others added 2 commits April 24, 2018 16:46

Verified

This commit was signed with the committer’s verified signature.
…encies
Moved all GUI manipulations for cancelled installation to FailWaitDialog() in MainWait.cs
@DasSkelett
Copy link
Member Author

DasSkelett commented Apr 24, 2018

So, I created a new FailWaitDialog() with error messages as parameters wich executes all GUI calls.
Also I deleted the HideWaitDialog() on CancelCurrentActionButton_Click() so the status log stays open and it's unneccessary with FailWaitDialog().

And because I have bad reflexes and I clicked cancel for testing too slow a lot of times, I realized, that after clicking cancel we don't check if the installation still concluded successfully, resulting in those now false error messages and the GUI not recognizing the newly installed mods.
See here:
cancelinstall

Edit: And I'll change the else block to use the new method, too.

@DasSkelett
Copy link
Member Author

Need to sleep a night about this as this is some high level sh*t which definitely exceeds my capabilities by now.

@HebaruSan HebaruSan dismissed their stale review April 24, 2018 20:26

Comments are addressed

@politas
Copy link
Member

politas commented Apr 25, 2018

this is some high level sh*t which definitely exceeds my capabilities

Boy, I know what that feels like!

Moved all GUI manipulations for cancelled installation to FailWaitDialog() in MainWait.cs
@DasSkelett
Copy link
Member Author

Okay this was some strange rebase...

Now clicking cancel first checks if everything was completed successfully despite cancling so there are no false error statements.
@DasSkelett
Copy link
Member Author

DasSkelett commented Apr 26, 2018

So I added the check if the installation completed despite "canceling", a bit hacky, but working (I think)
Not ready-to-merge yet, because for unknown causes the retry button stopped working and the GUI laggs shortly after canceling...

Edit: The build fail is not my fault! It's TravisCI which failed on connecting to network again.
Just in order to scotch any rumours...

Sorry, something went wrong.

@politas
Copy link
Member

politas commented Apr 27, 2018

What build fail? 😀

Sorry, something went wrong.

@politas
Copy link
Member

politas commented Oct 7, 2018

@DasSkelett , is this ready to merge, or are you still needing to work on it some more?

Sorry, something went wrong.

@DasSkelett
Copy link
Member Author

Hey, back again, sorry for the long wait.
I'll try to get behind what I did back then. As I just tested, if I cancel AFTER the install completed, it still says error, the "apply changes" button is still falsely active (not thaaaat bad, because if you click it it says already installed, but would be nicer if it would be deactivated) and the retry button moves to a buggy position.
I think I should open a new PR without all those rebase errors? @politas @HebaruSan

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
GUI Issues affecting the interactive GUI
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants