Now that `Library::getArchive()` never returns a null pointer the check
that was added a few commits ago as a fix for a particular manifestation
of a general problem is no longer needed.
Before this change a non-existent download directory would result in
"The system doesn't have enough storage available" error. Trying to save
files to non-writable directory resulted in the download seemingly being
stuck (but this is just a special case of not properly handling the download
error status returned by Aria).
`kiwix::Library::getArchiveById()` returns a `nullptr` when it turns out
that the ZIM file doesn't exist. That function was added in PR #536 and was
never documented, but that is no justification for us to let the
application crash.
`Qt::Key_F11` and `QKeySequence::FullScreen` are of different enum types
(`Qt::Key` and `QKeySequence::StandardKey`, respectively) with
overlapping value ranges. Using a standard integral type (int, unsigned,
long, etc) as a common type for them results in the type information
being lost and an ensuing impossibility to take advantage of overloaded
constructors of `QKeySequence`. The simple fix is to use `QKeySequence`
as the common type of the conditional expression.
Downloads that were active during the application shutdown automatically
resume.
Known issues:
- For paused downloads the progress information is lost (but is recovered
when the download is resumed).
Now the downloader paused/active state in UI is set by the updater
thread. This will make it easier to restore downloads after closing
and re-opening kiwix-desktop.
New ZIM files discovered in monitored directories are not added to the
library if they are known to be in the process of being downloaded by
kiwix-desktop. That information is recorded in the library as follows.
When a download is started the book is added to the local library with a
fake path that has a special suffix (".beingdownloadedbykiwix") appended
to the path of the ZIM file (previously, a book for which a download
was initiated had only its download id set and the path was added only
upon completion of the download).
Note that the expected path of the ZIM file is derived from the download
directory and the URL rather than obtained via
`kiwix::Download::getPath()` since the latter seems to return an empty
string until the download is actually started (it may stay queued if the
count of active downloads exceeds the queue size), the file is created
and `kiwix::Download::updateStatus()` is called after that which is too
late for our purposes (we want the information about a new download
to appear in the library before directory monitoring detects creation
of the file).
Known issues:
- If kiwix-desktop is closed while a download is still in progress
(either active or paused) then after reopening the app the information
about the download state is not shown in the UI and attempting to
download that file fails. However this problem is present before this
commit too (though in a slightly different way).
Before this change `ContentManager::reallyCancelBook()` could throw (and
thus result in a crash) if the confirmation to cancel the download was
timed to perform the actual download cancellation on a completed
download. This change fixes that problem. Besides it also fixes a subtle
issue where `ContentManager::reallyCancelBook()` is called on a
completed download and has the effect of removing the downloaded book
from the local library. I considered preserving that dubious behaviour,
but it couldn't be achieved in a simple and consistent fashion (because
of the two ways an actually completed download can be seen by the
`ContentManager::reallyCancelBook()` function).
My experience is that `kiwix::Download::getPath()` may return an empty
string (at least for a fresh download object and probably before Aria2
actually starts downloading and creates the target file). Passing such
an empty string into `eraseBookFilesFromComputer()` might have
disastrous consequences. Now that function should be safer.
Note that this change drops the protection against accidentally removing all
files in a book's directory. The risk of a such a destructive operation
is still present if an invalid path is passed into
`eraseBookFilesFromComputer()` but that will be addressed in a separate
commit.
