In imagedownloader.cpp the only thing we need from the picture struct
is the filename. Therefore, use QStrings instead of the picture struct.
This simplifies memory management.
Remove the clone_picture() function, which is not needed anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
SHashedImage was a subclass of QImage, which fetched the image according
to the filename hashes. Turn this into a function, as this is much more
idiomatic and flexible.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To ease trouble-shooting of the picture thumbnailer add a number
of debug- and info-messages.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
The hash field in the picture-structure was in principle non-operational.
It was set on loading, but never actually changed. The authoritative
hash comes from the filename->hash map.
Therefore, make this explicit by removing the hash field from the
picture structure.
Instead of filling the picture structure on loading, add the
hash directly to the filename->hash map. This is done in the
register_hash() function, which does not overwrite old entries.
I.e. the local hash has priority over the save-file. This
policy might be refined in the future.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
learnHash() was always called in conjunction with add_hash(). The
pattern was that a local filename and a hash were connected in
the hash-to-filename and the filename-to-hash maps. Then, the
original picture-filename or url were registered in the filename-to-hash
map.
This commit changes learnHash() to take three parameters (original-filename,
local-filename and hash) and do all of the above. The new code is
simpler because no dummy picture struct has to be generated in
DiveListView::loadImageFromURL().
The tests were extended to check for all hash<->filename associations.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
updateHash() and hashPicture() did the same thing, with the exception
that hashPicture() marked the dive list as changed if a hash changed.
This seems like a good idea in any case, therefore always use
hashPicture().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If loading from hash failed in the saveImage() slot(!) it would
recurse into loadFromUrl(), which would generate a new network
reply. Very scary and a (small) wonder that it worked.
Let's try to make this all more explicit.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The QNetworkAccessManager is only used in the load() function. No
point in it being a subobject.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
1) Destroying the QNetworkManager seems like a bug: this was a
subobject of ImageDonwloader. It's mysterious how this didn't
crash.
2) Instead of calling deleteLater() on the reply object, simply
delete it after completion.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
A cloned picture struct would not be freed if the filename was already
in the queued-for-download set.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The images to load are kept in a set to avoid multiple loading of
the same picture. The set was protected with a mutex.
Problem: the mutex was not released before loading the picture,
effectively serializing the loading of pictures.
Therefore unlock the mutex once the set is updated.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In core/imagedownloader.cpp the helpers cloudImageUrl() and loadPicture()
are made of static linkage.
The global variables queuedPictures and pictureQueueMutex were moved
into the loadPicture() function, because they are used only there.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Otherwise we keep downloading the same image multiple times instead
of new images.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Otherwise we step on our own feet when downloading several images,
like after import from divelogs.de with many linked images.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Having subsurface-core as a directory name really messes with
autocomplete and is obviously redundant. Simmilarly, qt-mobile caused an
autocomplete conflict and also was inconsistent with the desktop-widget
name for the directory containing the "other" UI.
And while cleaning up the resulting change in the path name for include
files, I decided to clean up those even more to make them consistent
overall.
This could have been handled in more commits, but since this requires a
make clean before the build, it seemed more sensible to do it all in one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
2016-04-04 22:33:58 -07:00
Renamed from subsurface-core/imagedownloader.cpp (Browse further)
