Qt 5.11 adds useful warnings when code attempts to use anchors within
Layouts and even tells you how to fix things.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to trigger the redraw of an edited dive we need to make sure
the model realizes that it has been updated. So far the only way to make
sure this happens reliably appears to be to remove the item and
re-insert it. Seems weird, but with this the bug of not redrawing the
profile after an edit appears fixed.
Fixes#1419
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The old trGettext() was not thread-safe and the returned C-strings
could be freed in the case of empty translations strings. Therefore:
1) Introduce a mutex protecting access to the cache.
2) Never change existing entries, even if the translation string is empty.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were a handfull instances of the kind
1) gettextFromC::instance()->tr(...)
2) gettextFromC::instance()->trGettext(...)
1) is pointless, as tr is a static function.
All instances of 2) were likewise pointless, because trGettext()
returns a C-string, which was then immediately converted to a
QString.
Thus, replace both constructs by gettextFromC::tr(...).
After this change there was only one user of gettextFromC::instance()
left, viz. the C-interface funtion trGettext(). Therefore, remove
gettextFromC::instance() and do all the caching / translating
directly in the global trGettext().
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The purpose of the gettextFromC class is twofold:
1) It provides a static storage of C strings if the C part needs
a translation and doesn't want to deal with memory-management.
2) It severs as a catch-all class for translations that do not come
from a proper class (i.e. from helper functions).
The second case was used a few times in qthelper.cpp. By using the
trGettext() function, a cached C-string was obtained. But in every
single instance, this C-string was then back-converted into a QString.
Therefore, use the gettextFromC::tr() function directly, which
returns a QString. Not only is the resulting code simpler - this also
avoids superfluous caching of translation strings.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
... by taking into acount that dive planner points refer
to the sement before the waypoint (while change mode
events are concerned with the future of a waypoint).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
When making a segment non-CCR, its setpoint should be 0.
OTOH, when it becomes CCR, use the default setpoint
(or should we try to find the last previous setpoint?)
Signed-off-by: Robert C. Helling <helling@atdotde.de>
There are actually more datatypes in bash than just strings. One can for
example hold a list of strings in a list, and use that to keep track of
what we're expected to do.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
The previous code assumed everything was good to go if just the tar ball
was there, but if it wasn't unpacked, it all went sideways.
This makes it more robust and to actually handle that the tarball might
just be there.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
remove mapWidget entries from subsurface.qrc, and
add reference to map-widget.qrc in CMakelist.txt
Android uses the same CMakelist.txt
Signed-off-by: Jan Iversen <jani@apache.org>
remove MapWidget entries from mobile-resources.qrc, and
reference map-widget.qrc in Subsurface-mobile.pro for iOS
Signed-off-by: Jan Iversen <jani@apache.org>
Owing to the recent churn in imagedownloader.cpp, some of the
code was bogus.
Notably, in f60343eebb the code
was changed such that always the local filename was used to access
the images. Yet, the old code remained, which after failure tried
again to access the local picture. This second access can obviously
be removed completely.
More seriously, after failing to load the local version, no
attempt was made to fetch the image via canonical filename. This
could produce the following sequence of events:
- Import remote image
- Delete thumbnail and local cache of image
- Image loading would fail
Therefore, first try to load using local file-location. If
that fails, load using the canonical file-location. To do
so, split the file-access code in two functions. The code
should now be distinctly easier to follow.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This way the user doesn't inadvertantly end up with information from a previous
run of Subsurface-mobile when they copy the logs to the clipboard.
Not sure we should do the same when building for desktop, so right now it's
only when building for a device.
Reported-by: Thomas Fänge <thomas.fange@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We filled in the missing information and then printed the wrong string.
This fixes that and also makes the strings slightly easier to understand.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This broke our hook to plumb in our usb open function into libusb, so
this broke ftdi based downloads.
This reverts commit e4530cd5ef.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
This should never happen, since our interface is bassically synchronous,
but it could happen with delayed replies that came in just after we
decided to re-transmit a command.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Our model of waiting for 100ms before re-checking if we got a packet
over BLE resulted in potentially horrendously bad latency for received
packets.
That isn't just a possible performance issue, it actually seems to cause
IO errors with my Suunto EON Core. I'm not entirely sure why, but it
might simply be some timing interaction, particularly since the IO
errors seemed to primarily happen when the dive computer itself was also
busy updating the screen (ie if you pressed buttons on the dive computer
to switch to compass mode, for example).
So replace the silly hardcoded 100ms "waitFor()" function with a
WAITFOR() macro that checks the provided expression every time through
the loop, which gets us a much lower latency (we basically check every
ten milliseconds).
The macro is not beautiful, but it WorksForMe(tm).
This makes a huge difference to the reliability of the download for me,
and might matter for some other dive computers too.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is based on something that Anton Ludin sent to the mailing list.
Reading through the code it seemed that there were scenarios in which
DC_vendor and DC_product were not updated correctly. That's one of the
problems of the declarative approach in QML - it can be very hard to
figure out which code is run when in certain situations.
This may help address the issue with FTDI downloads no longer working on
Android.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The asynchronous load seemed to be (at least one of) the culprit(s) of
the banner occasionally not showing up.
Making the font for the cloud ID smaller looks better (and works much
better for long email addresses).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We want to allow people to keep dives they collected without a cloud
account. The code was mostly there, we just got confused about the
existing status because we ran through this twice (no cloud -> unknown
-> verified). This way we explicitly remember this kind of transition.
Fixes#1404
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
That change clearly would have benefited from better code review.
This is a superset of a change proposed by Jan Iversen.
Closes#1406
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
MAX_TANK_INFO is defined in dive.h but is not
used in add_cylinder_description() or when
allocating 'tank_info'.
Use MAX_TANK_INFO instead of the literal 100.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Instead of a constant or a macro for the maximum
number of 'ws_info' elements the 100 literal was used.
Define MAX_WS_INFO in dive.h and use it everywhere.
Also clamp loops that iterate `ws_info' to MAX_WS_INFO.
Prevents potential out-of-bounds reading, similarly to
the previous commit about 'tank_info'.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
