Commit e21cae2d46 ("Cloud storage: sync the remote after save") broke
regular git saving without any remotes: it would never initialize the
"remote" pointer, and then use that uninitialized remote pointer to see
if it was a cloud storage remote that it should try to sync.
Fix it.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This got broken in a recent transition to more abstract models.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Switch the column order of the planner notes table so that duration is displayed before runtime. This is consistent with:
- the verbatim output order, e.g. "Stay at 12.0 m for 3:00 min - runtime 32:48 on EAN50"
- MultiDeco, e.g. http://www.hhssoftware.com/multideco/view_multideco.html
- Planner on the Shearwater Petrel
- How I have been taught to write out my dive plan in my wetnotes
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was a poorly implemented hack when we executed the reverse geo lookup
in the main thread and opening a V2 file could take a very long time. We
need to do the "Welcome" message quite differently.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't perfect, but at least tells the user if we weren't able to
connect and are working just off the local cache.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is mostly a proof of concept right now; it shows that it is possible
to create a headless server application that exports a git repository
based data file as html.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to be able to initiate an HTML export from the core library we
need to separate the actual logic from the UI.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems quite convoluted to me but I can't seem to make a more straight
forward implementation work. The idea is that core code should never
directly call into the UI.
So instead the core code (this is C code) calls a helper function. That
helper function calls a member function of a class which in return emits a
signal. The UI code connects to that signal and acts accordingly when it
is received.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This creates the basis to allow other backends to be used with the cloud
storage infrastructure.
So far this should all just transparently continue to work. A user would
have to manually add the cloud_base_url entry to the CloudStorage section
in their config file in order to use a different backend server.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
