When a file in the monitored directory is renamed, it is better to
remove the old file from the library before adding the new one.
Doing it the other way around will not work correctly - adding the new file
will fail since a book with that UUID is already present in the library,
and then that book will be removed!
Moved 3 member functions of Library related to directory from
library.cpp to contentmanager.cpp as is so that the changes made to them
when those functions are transferred to ContentManager are easier to
spot.
The purpose of LibraryManipulator defined in library.cpp was to emit the
booksChanged() signal for every book added to the library. In
Library::updateFromDir() we can do that once per call of that function.
Superficially there are some subtle difference between
KiwixApp::setupDirectoryMonitoring() and the part of the
KiwixApp::setMonitorDir() that was replaced by the former. But the end
result of this change should be the same.
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.
