This commit add a new DataError Variant for feeds that return 304.
Its expected behaviror and the current API of Source::into_feed
is kinda limiting the return type to make it easier to handle.
Up till now 304 was returning an Error to early return. Ideally
Source::into_feed will return a Multi variant Result Enum.
example:
enum FeedResult {
Ok(Success(feed)),
Ok(NotModified),
Err(err),
}
Hopefully in a refactor in the near Future™
Till then we will just have to match and ignore
DataError::FeedNotModified.
While the HomeView and ShowView can't yet scale that low,
the ShowWidget could get to about 270p already which is not
desirable.
This commit sets the minimum width of all the Views to 360p,
which is our mobile target size.
This reverts commit e64883eecb
and 40dd2d6923
Seems like core.run() returns once its done even if there
are still tasks in the Runtime underneath. A way to solve that
would be to call the shutdown_on_idle method.
We need ownership of the threadpool in order to invoke
`shutdown_on_idle` method but core.runtime only returns a
referrence so we need to create our own threadpool.
This requires a RUSTFLAG to be set before hand for rayon to build.
This brakes a lot of tools like rls and clippy by default and
require special configs for itnegration.
Additionally, rayon_futures is still 0.1 and not much work seem
to have gone into it. Ideally it should be replased with the tokio
runtime/threadpool.
Before we were inserting the id of the cover into the registry
from a rayon thread. But rayon will only execute N threads at the
same time and let the rest into a queue. This would casue mutliple
jobs being queued since the cover id was not inserted in the
registry until the downloading had started.
This fixes said behavior by having the main thread block and write
in the id in the registry.
Since loadign a pixbuf from the pre-rendered cache is the most
common operation and it does not affect the behavior we can
first check that and then if the cover is midway downloading.
This avoids a mutex lock for the most common path.
Accidently after f21398357b when a download would start,
it would lock the cover_dl_registry hashmap till it had finished.
Since the registry.read() happens on the main thread this would
cause the UI to block until the download was and the mutex guard
from the download thread dropped.
This adds a configuration option in meson, if set it changes the
application ID allowing for stable and development version to be
run at the same time.
