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>
In commit 25aa80846b ("Move Dive class from qthelper.h/cpp to it's own file")
the meaning of getting the "date" of a dive was changed to just be the date and
not the date and time. That's not what the QML code expected.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
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>
