The files collected were never opened, this all is just the result of
a copy and paste job that clearly was never fully thought through.
Also remove support for ancient libgit2
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>
The logic looked so easy, but the preference needs to be hard coded twice
because there are two scenarios:
- new install, make sure we load the password from settings (so it needs
to be hard coded BEFORE we load preferences)
- update where previously for some reason the user stored that they
didn't want to store the password, so we need to also hard code it after
the settings were loaded
Looks odd, but that should do the trick.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
commit d99c931219 ("QML UI: remove the checkbox for remembering the
password") made the incorrect assumption that this would always be true
by default when it actually was false by default. Oops.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We do not not want to do decompress model calculations in the mobile app
(see 130f4cd7ac), but we do want to see the divecomputer reported
ceiling (in red). The latter is fixed here.
Ticket #1006
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is overly simplistic and it would be better to be able to override this in
the settings, but frankly fewer settings are better and in most cases this is
what the user wants.
Fixes#987
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The asynchronous nature of the profile bites us here. plotDive() signals
that it changes model data and expects the rest of the data structures to
respond to that. Very neat and it seems to work perfectly well on the
desktop, but on Android calling render() right after plotDive() resulted
in paint() functions being called before all the elements had been
calculated as a result of the signals being emitted in the model change.
That's why so often the profile was missing parts.
Now admittedly this makes me nervous. Do we now know that all calculations
have finished by the time render() gets called? Not really. It just seems
that in my testing we tend to get lucky and things work out. But that does
not feel like a sane architecture to me.
Messing around with the animation speed is silly as we render the profile
into a pixmap, so let's turn this off globally.
Also, the scaling of the pixmap is still completely bogus.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The persistent storage of the preferences includes the Organization name
set in the application. So we need to make sure we load the preferences
AFTER setting up the Organization in the init_ui() call.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
