We probably want to change that on the prefs struct too.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Rename a few methods wrongly named and place them on the correct place on the file.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On the desktop we have long had this vision of a minimum length and a
"pleasant" duration of the profile - but on a device this seems to look
like uneven margins. So let's just add space for the labels and not
otherwise mess with the duration.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It was becomming too big, a smaller class is nicer to work wirh
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Also, the QtHelper.cpp file told me that some propertiies
where also TecDetails, graph related, so I moved them
to the correct preferences.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I didn't allowed the build on CMake for those files yet because
there will be tons of breackage, so when I finish, I'll allow.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This class needs to have all settings in Q_PROPERTIES
so it can be used in QML. I know we will not use all of the
settings in a visible way for the user on the QML app, but
we might increase things in the future and on different
form factors so it's good to be prepared.
Currently I implemented all of the possible properties, but
I still need to hoock up everything.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This finishes the first round of Simplication patches for the QML
basecode. The second one will be about the preferences.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And also use existing helper function to get the GPS string
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I didn't understood the logic of the define & replace,
so maybe we want a few comments there.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The connection between the C++ core and the QML code leaves a lot of room
for improvement; the following series will do small but important updates
on the code regarding QML and QtWidget coexistence and behavior.
First: simplify wrapper class, removing uneeded variable.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This compiled just fine for me but apparently the QStringList needs to be
explicitly included on Ubuntu 15.10.
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>
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>
