Fix DownloadManager and a few code improvements#2356
Fix DownloadManager and a few code improvements#2356mick-lue wants to merge 3 commits intoModOrganizer2:masterfrom
Conversation
|
I'll probably split this PR up into more digestible pieces. That'll take a few days though |
|
We were planning to look at this soon but if you think that would be better. I'll admit I wasn't sure how relevant all the emplace_back and lambda scope changes were to the download manager. |
|
yea it is unrelated as I went through basically the whole code base doing that when I needed a break from figuring out the DownloadManager. It does make MO2 a bit faster though (and the scope changes are for making intentionality clear). |
|
Rather than complexifying things, I'd probably rebase a couple branches and make separate PRs, I think. |
Hi there,
I have been wanting to fix the stuck downloads for quite a while now and finally managed to do it.
In the meantime, I've gone through most of the other code and (with the help of static analysis) found a few instances of possible improvements.
MO runs completely fine for me now and have had no issues. I've already reverted changes that were causing issues for me (before pushing the changes that is) and didn't find any more funky behavior.
The commented-out code can be deleted if it won't be used anymore.
Main Change (DownloadManager)
aboutToUpdate()only when we will also emitupdate()(otherwise we useupdate(downloadInfo))writeData(info)now does more checks to protect from failed actionsgetFileNameFromNetworkReply(QNetworkReply* reply)downloadFinishedNotable Changes
typeId()instead oftype()GeometrySettings::saveDocks(const QMainWindow* mw)andGeometrySettings::restoreDocks(const QMainWindow* mw)as its comment states that the issue is long fixed in QtGeneric Changes
&isEmpty()instead ofsize() == 0