While it makes sense to have the concept of "what's in memory" and "what's on
disk" in a desktop application, on a mobile device that seems like the wrong
approach. If the user edits a dive and taps on "save", they reasonably expect
this to be saved to storage (so our local cache of the remote git repository).
And "Upload to cloud" then pushes the data to the cloud server. It may even be
reasonable to do that automagically, but that I'm not so sure about.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Otherwise, if the device is offline we would not be able to store changes in
the local cache, completely defeating the purpose.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This has been the cause of issues in several cases. We should simply always try
to push all data to the server - it deals with redundant uploads quite nicely.
(previous commits already stopped responding to this flag, this simply removes
all mention of it)
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
- load the data from settings as we start
- improve upload to server
- keep settings and in memory model in sync
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of using the Settings as our data structure and constantly accessing
them, we now have a QMap for the GPS fixes and only access the Settings to keep
them in sync with the QMap. This should significantly speed things up.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This will use the depth units from user preferences when exporting the
worldmap.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Of course, as of this writing, there are no images on the server.
In addition, this patch adds comments to explain the by now convoluted
image retrieval logic (local file, filename as URL, by hash, cloud server).
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As Linus pointed out in mail list, user is forced to manually renumber
his dives after doing a merge, unless the merged dives were those at
the list tail.
This patch try to manage the more usual cases, letting the user to deal
with those more complex, based on some assumptions:
1.- We are working on an time ordered list of type:
dive_table.nr ... 100 -- 101 -- 102 -- 103 -- 104 ...
dive_table.dives.number ... 234 -- 235 -- 236 -- 245 -- 246 ...
2.- It's unlikely to merge no consecutive dives, as merging is time
based.
3.- It's unlikely (although possible) to find consecutive dives with
no consecutive numbers.
4.- It would be rather bizarre to find that newer dive,of those to
merge, has lower number than older.
5.- It can be found that one (or both) dives to merge are zero
numbered.
6.- There is only need to renumber from merged dives in advance.
A variable, "factor", is fixed before reworking the dive table. This
number will be substracted from the original dive number.
If we are in point 5.- case, "factor" will be set to zero, meaning
that dive numbers will not change (if older dive is zero, merged one
will be numbered zero too and will let the user to manage this; if
newer dive is zero there won't be need of renumbering as following
dives will be correctly numbered, e.g. after splitting a dive which
is not at the tail of the table).
In most cases, "factor" *should* be set to 1.
While renumbering it can be found a dive with it's number set to zero,
this won't be changed and will remain zeroed to avoid negative
numbers. It, mostly, means that the user has pending work on his
dives.
I don't know why I've written such a big explanation for such a tiny
patch :-)
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Small error was introduced in commit 25aa80846b. The dive.location was
shown in the DiveList instead of the intended dive.number
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This only deletes the fix on the mobile device, not on the server.
And it is really really slow. Re-reading the data from the settings just isn't
a smart way to do this.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Just having the string means we lost the unique value that we can use as key to
indentify a specific GPS fix.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is just the UI, the actual deletion is not yet implemented.
I really like this interaction with the list items. Slide them to the left and
you see icons for actions. Right now we have just one and that may seem like
overkill (hey, we could just have the delete icon instead of the application
menu icon, right?) but once we allow the ability to show the GPS location on a
map we'll have two operations and this will make more sense.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since commit c496d5fa05 ("Add helper script to pull Plasma Mobile Components
and icons") we had three different spots where we retrieved the Plasma Mobile
Components. That's a wee bit of overkill. So instead have the other two scripts
just call this one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We forgot to delete the Grantlee object before creating a new one
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We don't need a list of QFileInfo if we are not using it
much better to have a list of the files directly
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Set the values directly, seems much more sane.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
instead of duplicate the code that only chaged the QList that it
would access, create a temporary list and use it for dealing
with the code.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Normally this is done in the build.sh script when building
Subsurface-mobile - but some people might have set up their build
enviroment differently and for them this allows to pull (and update) these
components from upstream without having to run build.sh
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we alreday have a Q_PROPERTY on the DiveObjectHelper,
grantlee introspection can use that directly to access it's
data, so there's no need for us to redeclare everything.
More QObject Introspection, Less handmade boilerplate for
Grantlee, QML, and a few other things.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
it was taking 3 - 4 secs here to open the print dialog,
first I tought it was a bug in our side, but it looks like
it's a Qt bug, and by lazy initializing it we don't actually
solve this, since it will still take 3 - 4 secs for the printer
to start, but the dialog will appear much quicker.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
and rename it to DiveObjectHelper, since it should be an QObject
based class to make it easier on the QML, grantlee and widgets
side to display the dive's internal data.
each Q_PROPERTY defined in the DiveObjectHelper.h file
can be acessed directly via it's name.
So, if you are on a model that returns a dive, acess it's name
by dive.name
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
with the adittion of gpslistmodel/location, the libraries
qt-models had a direct dependency on subsurface-core, and
subsurface-core had a direct dependency on qt-models, this is
bad.
Moving a bit of code around I'v managed to clean this out, and
also to clear a bit of uneeded code (GpsTracker and gpsTracker where
basically the same thing.)
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While the conversion of uint64_t to QVariant works fine with some Qt /
compiler combinations, it fails on others. Use Qt's type instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
automake is recommended by autoconf, but depending on the
configuration, the recommended packages might not be installed. Thus
it is better to have it explicitly listed.
Signed-off-by: Miika Turkia <miika.turkia@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When starting ssrf-mobile, and the local divelist is identical to the
cloud version (so same sha1), a save of local modifications to the
cloud should be possible. This fix enables this by pretending
that a suppressed load from cloud on start is still a valid load
from cloud.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This had been broken by mistake in commit e5f95daee8 ("QML UI: reimplement
context menu for dive details").
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
So far the user can't interact with these. We should implement an ability to
visualize the GPS fix and to delete it.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is not the same as the existing download to apply the gps fixes to the
dive list. This allows us to download and store the GPS fixes in the settings.
I may end up changing things around to have a shared implementation for
downloading the GPS fixes, but for now this seemed easier.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
At the moment, if we have, say, dives ... 100, 101 and 102 and we merge 101 and
102, we get a list numbered ... 99, 100, 102. This is, probably, an
undesired behavior. The patch simple chooses lower of both dive numbers instead
of higher one.
Signed-off-by: Salvador Cuñat <salvador.cunat@gmail.com>
Acked-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
