When first tested this commit, especially the dive list was looking
terrible. However, after including newer SHA's from libkirigami, and
correcting lots of spacing/margin issue, a retest of this commit shows
no strange artifact any more, and the amount of warnings in the log
output is reduced significantly. So now, it appears save to
upgrade.
Notice that main.qml still uses Kirigami 2.0. and is not updated in
this commit. With version 2.2, there is a new way of theming, that
is not (yet) compatible with our current code. Blindly upgrading to
2.2 leads to a almost black dive list, wrong button colors, and
runtime errors in the log, due to the fact the direct setting from
QML Kirigami's Theme colors is not allowed any more.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Trip headers spanning more than one line where broken at incorrect
locations in the string. Not exactly sure, but I think this came with
the newest Kirigami SHA, and especially the Label change.
Carefully reading the code for the trip heading shows a "strange"
negative margin. So the margin is on the outside. This margin was
used to split the string, allowing for a small invisible part of
the string to present as trip header.
This is solved by this commit.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
The new SHA for Kirigami did all kinds of nasty things to our DiveList.
This commit tries to repair most of the damage. Nothing more than
some margins, anchors, and even a font that changed.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Commit 8f6827ab12 brought a new SHA for Kirigami, but that introduces
a very noisy logging of "Kirigami.Label is deprecated. Use
QtQuickControls2.Label instead".
So, thats what done here.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This addresses some review comment on whitespace and translated
string formatting.
In the string formatting, a tiny additional change is made.
I wanted the email address in the explanation text in a bold
font. Using the HTML <b> for this, removed the /n newline
characters in the output. Apparantly, mixing these two
formatting styles does not work. No problem, replaced the
/n to HTML style too.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This commit tries to implement most of issue #515. It reworks the
one credential page, which its dynamic PIN part, into two pages.
Main driver of selecting one of the two pages is the showPin
boolean. Page 1 contains the email/passwd field (and the
option to use a no cloud setup). Page 2 only contains the PIN
part (and the option to cancel the process).
The Kirigami central button does not seem very handy here. We
need, for example, a cancel, sign-in and register, only register,
etc. buttons, which are not easy to handle in specific icons.
Therefore, normal pushbuttons are chosen to deal with user
interaction, and the Kirigami button is removed from these
pages.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
It appears that the onCompleted of the StartPage item is triggered
before the onCompleted of the rootItem. This is logical as the
Startpage is a child of the rootItem. And, yes, this does matter.
As the divelist also contains the logic for initial cloud
registration (and is the default page shown in a state where
the cloud credentials are valid (CS_VERIFIED state)), we need to
know the correct credential state at start of the app.
The move of this one line of code makes sure of that, in addition
to setting the credential state from the preferences. Now, the
setupActions function can reference correct credential data.
This is further preparation for a better cloud creation
process from mobile.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Having two different enums around with more or less the same
definition has lead to unclear code. After removing two not needed
states on the mobile end, the remaining step to one enum for the
credential state becomes almost is simple rename operation.
Unfortunately, I do not know a way to embed a plain C enum
from pref.h into the QMLManager object. So after this, there
are still 2 enums around, but now identical.
This commit is not changing any functionality.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This is a no-brainer removal of the VALID_EMAIL state used in QMLManager.
All current usage of this state is "if state is VALID or VALID_EMAIL",
so there is no distinction between the two states.
It is even a little different. The comment suggests "when we can open
a local cloud storage, tied to a cloud account (so explicitly not
the no-cloud status), we have at least a valid email". While this
is formally true, this implies that there is also a cloud account
on the cloud server (ie. the cloud account is in a VERIFIED state).
In other words: currently, there can't exist a valid local storage
that is tied to a valid email adress, without valid cloud account
on the server.
Notice that this touches the discussion on GitHub for commit
e76f527fe5 (pull request #520). Can we implement the creation
of a valid cloud account without data link to the cloud server?
Currently, we need the server to confirm the email address (for
example for uniqueness reasons on server side). Obviously, we could
hack our way out of this, but we have a perfect solution already
in place. Create a no-cloud account, and transfer that later to
a true and valid cloud account.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This appears to fix the mystery crashes that can occur when deleting a dive
from the dive list.
Fixes: #497
Signed-off-by: Rick Walsh <rickmwalsh@gmail.com>
Fast flicking to the top of the divelist triggers almost certainly a
pull down sync, as the default boundBehavior is DragAndOvershootBounds.
Despite being the default QML action, this leads to unwanted pull
down syncs (even in offline mode).
Setting the boundBehavior to DragOverBounds solves this issue. Now,
the user has to explicitly drag the top down to force a pull down
sync, and a accidental fast flick is stopped at the upper bound.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Now that we support this for many dive computers, that seem reasonable.
I'm not happy with the icon, but couldn't figure out a better one in the
breeze icon set.
See #426
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This isn't great, yet, but a first step to show that this is possible
(and in doing so I found quite a few spots where the colors weren't
correctly propagating, yet).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we have distinct colors for trip header and selected dive, this
is actually counter productive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Make the accent color much lighter, don't have a solid bar on the left
for dives that are part of a trip.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In order to make it easier to see the changes, the code hasn't been re-indented.
This will be in the next commit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way it will render in the same font as the location of a dive.
This will look like crap until the next commit adds a rectangle with
color around it, but this way it's much easier to see the individual
changes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Based on Davide's ideas, but with a few tweaks:
I really like the dive number on the far right; that gives a clean
consistent look. I tried it with date on the left and depth/duration in
the middle and liked the result.
This doesn't change the font, just addresses the layout and bold heading
vs smaller sub-heading.
See #427
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Fixes scrolling of the cloud credentials and simplifies code
Signed-off-by: Marco Martin <notmart@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Completely adapt to the api changes of OverlaySheet in Kirigami2
in order to achieve the same look and behavior for the dive
edits that had with kirigami1
Port most components to QtQuickContrls2, except comboboxes
in the dive edit sheet that will need a new control type
Signed-off-by: Marco Martin <notmart@gmail.com>
It's unclear why this code was added in the first place - removing it
makes the highlight of the selected dive in the dive list work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
