Prevent doing mod list refresh while there are active mod downloads

[VilppeRiskidev]

No description provided.

[VilppeRiskidev]

I might do some more testing locally, I'm 85% confident in these changes.

[anttimaki]

If user visits the SettingsView of ProfileImportModal (and asumably ModListUpdateBanner which I did't test), they look like user could start the mod list refresh, but clicking them does nothing and gives no feedback of any sort. I would suggest we add "if active downloads" check to those UI components and tell the user to wait until the mod downloads finishes.

This is somewhat minor thing, but I think it should be rather easy to address.

[VilppeRiskidev]

If user visits the SettingsView of ProfileImportModal (and asumably ModListUpdateBanner which I did't test), they look like user could start the mod list refresh, but clicking them does nothing and gives no feedback of any sort. I would suggest we add "if active downloads" check to those UI components and tell the user to wait until the mod downloads finishes.

This is somewhat minor thing, but I think it should be rather easy to address.

Created a PR for this: #1646

[anttimaki]

Created a PR for this: #1646

IIRC we discussed recently that fixing issues in one PR in another PR don't always make sense, since it just increases the number of open PRs if the first one can't be merged before the second one is ready to merged. I'd say this is one of those cases, as merging these changes without the other UI changes would result in an awkward version of the manager.

You could perhaps use git's cherry-pick to include the commit from #1646 in this one and close #1646. Or close this one and make #1646, including this commit, point to #1633.

[VilppeRiskidev]

Created a PR for this: #1646

IIRC we discussed recently that fixing issues in one PR in another PR don't always make sense, since it just increases the number of open PRs if the first one can't be merged before the second one is ready to merged. I'd say this is one of those cases, as merging these changes without the other UI changes would result in an awkward version of the manager.

You could perhaps use git's cherry-pick to include the commit from #1646 in this one and close #1646. Or close this one and make #1646, including this commit, point to #1633.

Did the second option so I'll close this one.