If the user didn't enable saving the password to the preferences, then the
password was cleared out as the preferences got synced.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes it clear that we are working with the cloud storage and removes
the (in that case, redundant) branch name from the title.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
libgit2 takes forever (a minute or so) to figure out that it can't connect
to a remote server.
So if we are using https as connection protocol, quickly check utilizing
RFCs 2324/7168 to make sure we can reach the cloud server (and not some
captive portal or something).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The settings are stored in the local cache repository - so without
resetting it a proxy would stay configured even if it was disabled in the
Subsurface preferences.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At the time of this commit support for this feature has not landed in
upstream libgit2, yet (but there is a pull request). Yet supporting this
here doesn't appear to cause any issue with older versions of libgit2,
either, so the http proxy support will simply not work when enabled and a
version of libgit2 that's too old is used.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems to work better than moving the Globe up there.
It's not ideal (I really want to be able to show one big picture for the
site - and on all the sites without pictures we show nothing), but for now
I think this is better than having the profile there.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reverts commit ec8ba5f830.
Turns out that moving the globeGps widget to a different quadrant breaks
the parent relationship and that causes things not to work. I know that I
tested this and didn't notice any issues, but I now can reproduce a broken
default screen. So let's revert.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This includes trips, dives outside trips, deco, gas changes, dives with
multiple dive computers, a really short dive, a rather long dive, a dive
with pictures, dive computers with very coarse sample rate, rather fine
sample rate, with gas integration, without...
Should touch a lot of different scenarios.
The file is in V2 format to also allow testing the importing / conversion
to dive sites.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Again, note that this currently only happens when you initially open the repository.
So if you do
subsurface https://.../repo[myubranch]
it will start up by fetching the remote information, and updating the
local cache. If you then download new dives, and do a save-and-exit, it
will save to the local cache, but it doesn't do the fetch at this point,
so the remote is now begind.
The *next* time you start subsurface, and load that git branch again, it
will fetch the remote, and now notice that the local cache is ahead of
it (because you downloaded new dives and saved them locally), and *then*
it will try to update the remote with the new information.
This is obviously bogus, but we will need to decide exactly how we want
to sync with the remote repository. But now the core functionality is
there, it's just that we need some interface to say "sync now".
Especially in the face of spotty (or non-working) internet, you want a
GUI etc for this whole remote sync, rather than doing it unconditionally
and silently whenever you load the local cache initially.
With that caveat:
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm going to try to update the remote if the local cache is more recent
when we fetch the data, which requires access to the remote over a wider
range of code. This re-organizes the code so that we can free the
remote later without having to have nasty error handling.
We avoid the whole "if an error happened, free the remote and return" by
creating helper functions and freeing the remote in the caller, so that
all paths end up freeing it naturally.
NOTE! We want to try to update the remote when we save the local cache
too, so this whole "update remote when opening it" is incomplete. But
(a) we do want to do it here as well
and
(b) this is the easiest place to create the initial "push to remote"
code without any new "sync with cloud" interfaces.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We used to fetch the remote information but not actually do anything
about it, except report when it wasn't up-to-date.
Now we actually update the local cached copy if the remote has changed.
The code does not try to actually merge things, so only fast-forward
updates are done, but that should be the normal case. We might
eventually do some simple merging on our own, but I suspect manual
merging may be the safer option.
We don't currently ever update the remote repository, and only inform
users that our local repository is ahead of the remote. Fixing that is
the next step.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While this isn't what I really want (I wanted pictures of the dive site
instead of the profile), at least this makes it clear that we aren't
editing a dive but instead are looking at a site.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This now happens in its own thread...
But leave the infrastructure so we can ask questions about the geo
encoding
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Two "locations" from a V2 file are the same site if they have the same
name AND if their GPS coordinates are within 20 meters of each other.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And use this to find a dive site within a certain radius of a GPS fix.
This will be used to figure out if dive sites might be the same.
This uses a new Qt5 component (Positioning) which was added in Qt5.2.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we should have far fewer dive computers than dives this straight
forward algorithm shouldn't cause any performance issues.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The algorithm seems rather brute force; basically quadratic in the number
of dives, assuming we have about the same number of dive sites as dives
which seems a reasonable assumotion.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When downloading GPS data from the Subsurface webservice we repopulated
the globe before purging all the unused GPS fixes from the list of dive
sites which caused massive clutter (until the next time the user changed
the displayed dive or did anything else that caused the globe to redraw
itself).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we use the email address (including the '@' sign) as the repository
name we have to be more careful when trying to pick an account name from a
git URL.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
After we import all the GPS fixes from the Subsurfae webservice we delete
the ones that didn't match any dives. The algorithm skipped every other
one by mistake.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The Subsurface Webservice (as backend for the companion app) will usually
send a lot of gps fixes encoded as dives, all with the same dive site
name. When parsing the XML file it sends we need to make the dive site
names unique so that we can then match them to the existing dives.
The fake dives with all the dives sites will all be discarded, but without
creating the unique dive sites we can't successfully add the GPS
coordinates to the existing dives.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We can't build with -DNO_MARBLE after some previous commit broke
globe.cpp
- centerOnCurrentDive() is still existing in the code while removed from
header in 6b81fb49d0.
- Some referenced to MainWindow::instance()->globe() even if we are
building with no marble.
- include stdint.h
Signed-off-by: Gehad elrobey <gehadelrobey@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This triggers when the email address / password is changed in the
preferences. It opens an https connection with the backend server (the URL
is hardcoded) which should create an account with these credentials.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we added two dives, and then tried to edit
the first added one, the current 'added dive'
set on main_tab would be the second one, so when
we got to the accept() part of the call, it would
reselect the last added_dive that we had.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The name of the dive site on the globe wasn't being
updated when we changed the name of it in the dive
management dialog.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were ignoring the displayed_dive_site
as we were adding it and the changes weren't
accepted yet.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We always thought that a dive had a dive site
and that a dive really exists. but if we go
to add dive and then go to add dive site,
none of those exist yet and then we got a crash.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the current_dive was the same as the dive send to
the LocationInformation widget, we would do nothing,
wich is wrong because we could have filled the information
on an add_dive_site action and then cancelled it, so the
info will stay there until we change it.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
