This just deals with the mechanics. There is no UI to enter / change this
URL (and that's intentional), neither is it used, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The implementation in commit 182fe790c9 ("Add ability to undo
renumbering of dives") looks perfectly reasonable, but it depends on an
implementation detail: it assumes that the keys of the QMap are returned
in the same order in which they were placed there. Which apparently isn't
the case for some version of Qt.
With this commit we simply remember both the old and the new number for
each dive and therefore the order in which they are processed doesn't
matter.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This fixes a "reproducable hang when using "edit dive in planner" on
non-planned dive".
Comparing unsigned and signed integers isn't a great idea.
Fixes#880
Signed-off-by: Jan Darowski <jan.darowski@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I have no idea whether the semantics is right, this patch was only
written so Subsurface compiles against the current stable release of
libgit2.
[Dirk Hohndel: added an extra conditional so this also compiles with the
curl-stream branch needed for https proxy support in
libgit2]
Signed-off-by: Gaetan Bisson <bisson@archlinux.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we don't have verified cloud credentials disable the menu options and
disallow the use of cloud storage as default data file.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Correctly tracking the status of our authentication with the cloud service
is non-trivial, especially since the user may quit Subsurface between
registering and verifying an account, they might even register on one
machine and verify on another.
This tries to make sure that when in doubt we check with the cloud service
backend. And we show errors in the UI.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Subsurface will now start with the no default file, the local default file
or cloud storage as chosen in the preferences.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This now sets the preference variable / config entry and keeps them in
sync. Doesn't actually change the behavior at program start, yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So for now just keep using the same function as we use with earlier
versions of Qt5 as that seems to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This simplifies the distance calculations and removes a dependency.
This version uses propper math instead of my to simple previous version.
Signed-off-by: Anton Lundin <glance@acc.umu.se>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We were falling of the end of a number of functions that were supposed to
return 0 on success or an error.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no point in telling the user that the remote is empty. We need to
instead fix that and create the local cache and set things up for the
remote.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we first store things to the remote there won't be a matching branch
for it. And even if for some silly reason the remote branch got lost -
what's the point of telling the user that there is no remote branch? What
are they supposed to do about it. Let's just fix the problem and move on.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And add a parameter that tells it whether to try to save any Subsurface
data or whether to just create a branch and push it out.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Yes, this could easily done from the C code. But this seems just so much
easier and I don't have to worry about the oddities of Windows and all
that.
I'm lazy. So sue me.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Once we failed to load data from cloud storage (for example the first time
we try to use it when the remote repository is empty), don't show git
related errors to the user. It's enough to tell them that the cloud
storage is empty.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we don't have a repository yet, we can't setup the proxy option before
calling into libgit2. Instead we use a callback.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The lower level functions will already report that things didn't connect
successfully, no reason to repeat it here (which then exposes the git
URL).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of showing the git URL and talking about failures to clone
repositories, simply tell the user what's happening with the cloud
storage.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also change the name of the enum and make sure all the inner functions get
passed the remote transport information.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This change once again tests if the remote can be reached. Even with a
fairly big data file and a medium speed internet connection the remote
sync is fast enough to call it nearly instantaneous. Maybe a couple of
seconds.
We may need more checks / different heuristics / warnings if the sync
didn't happen, etc. But for now this should allow more reasonable testing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
