Separated checks that can be performed early (independent of aria2c
services). When the download initiation is converted to a 2-stage
procedure (similar to how it was done for pausing/resuming/cancelling
a download) those checks better be performed synchronously in the main
thread.
Pausing a download now changes its state to PAUSE_REQUESTED and the
pause request is enqueued for asynchronous execution. Similarly,
resuming a download changes its state to RESUME_REQUESTED and the resume
request is enqueued for asynchronous execution.
In the PAUSE_REQUESTED and RESUME_REQUESTED states download actions
are disabled.
Known issues:
- The PAUSE_REQUESTED state may be incorrectly restored to DOWNLOADING
if at the time of pausing an earlier UPDATE request for the same
download preceded it in the queue or was being executed. After
the response to the said UPDATE request is received it results
in the DownloadState being reset to the previous state. But after
the pause request is processed a subsequent UPDATE request will
change the state to PAUSED. In GUI this looks as follows (assuming
slow responses from aria2c, allowing to observe the events in slow
motion):
1. Pause button is pressed
2. Pause button and download progress info (the textual one) disappear
3. Pause button and download progress info (the textual one) re-appear
4. Download switches to paused state without any further user actions
A similar problem exists for resuming the download.
The solution is to convert the request queue to a priority queue
where download actions are given precedence over update actions.
However this will not eliminate the problem completely since a
pause/resume action may be issued while an update request is being
processed by aria2c (the likelyhood of which greatly increases if
aria is mostly stuck struggling with slow storage). The latter
case will be addressed by tracking the timestamps of the requests
and ignoring the download status from those update requests that
were issued before the user action requests.
Made the download updater thread process requests from a queue.
Such a scheme paves the path to performing all download actions
asynchronously by placing them onto the queue (which will eliminate
non-responsiveness of the application when those commands hit the
problem with slow responses from aria2c).
If download info becomes stale (due to slow responses from aria)
the download speed is shown as ---.
Known issues:
- A stale download is refreshed only due to a GUI event (such
as scrolling or mouse hover).
The binary flag DownloadState::paused was replaced with a richer
DownloadState::status but the old logic of distinguishing only
between active and paused downloads still remains.
Before this fix when kiwix-desktop was launched with a paused download
inherited from a previous session, cancelling that download didn't
remove the download files (incomplete .zim and .zim.aria2 files) because
the path of a paused Aria2 download is not available until it is
resumed. Now the path of a book being downloaded is taken from the
library (thanks to the previous commit).
When a book is downloaded via a metalink URL the fake path (with a
".beingdownloadedbykiwix" suffix appended to it) recorded for it in
the library could not in general be used to obtain the real name (and,
hence, path) of the ZIM file. Now the book path is "corrected" as soon
as the file name becomes available.
