| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
By now, it's a recurring pattern of wanting to restrict aborting in
certain situations. This avoids further code duplication, and adds a
signal that external users can hook up to to respond to such change.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: Sefa Eyeoglu <contact@scrumplex.net>
|
|
This allows us to emit all the necessary stuff when we're finished in
the case of starting a task with no subtasks. In particular, this caused
the mod updater to not work properly :)
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
It's not a good idea to have multiple concurrent tasks running on a
sequential thing like this one.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
In a way, sequential tasks are just concurrent tasks with only a single
task running concurrently, so we can remove LOTS of duplicated logic :)
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
This fixes an annoying issue where concurrent tasks would try to start
multiple tasks even when there was not that many tasks to run in the
first place, causing some amount of log spam.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
|
|
This makes it possible to run a task in another thread.
I added a variable to toggle debug prints because they seem to trigger
an assertion on Qt internals when the task in on another thread. Of
course, this isn't awesome, but can wait until we improve our logging.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Heavy workloads can consume a ton of time doing their stuff, and starve
the event loop out of events. This adds an event processing call after
every concurrent task has been completed, to decrease the event loop
stravation on such loads.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
This is a variation of a Sequential Task, in which a subtask failing
will prompt the next one to execute, and a subtask being successful will
stop the task.
This way, this can be used for easily managing fallbacks with tasks. :D
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Previously, it would not update the global counter if the subTask didn't
update its progress, even though progress was being made.
This also prevents a segmentation fault while aborting the task.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
Refactor tests
|
|
This tasks (or rather, meta-task) has the ability to run several other
sub tasks concurrently.
Signed-off-by: flow <flowlnlnln@gmail.com>
|
|
|
|
Add on-disk mod metadata information
|
|
|
|
|
|
- Fix aborting sequential tasks
- Fix displaying wrong number of tasks concluded
- Fix text cutting when the URL is too big
|
|
|
|
Also remove some unused imports
|
|
Also sets up correctly the status connections
|
|
Since now we're inheriting from Task, some signals can be reused.
|
|
This also reduces some code duplication by using some Task logic in
NetAction.
|
|
Also adds one more check to setStatus test
|
|
Only only two tests for now. We can iterate on this later :^)
This is to try to avoid breaking things again!
|
|
|
|
This puts all mod downloading tasks inside a SequentialTask, which is,
for more than one task, a multi step task. This is handled by the
ProgressDialog by showing both the global progress of tasks executed,
and the individual progress of each of them.
|
|
|
|
|
|
|
|
|
|
|
