Create small visible separation from the dive trip before. And make the dive
trip header a slightly different color so they stand out between dives.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes it MUCH easier to deal with a lot of dives.
Instead of needing a more complicated model we simply use the meta data that
allows us to create the dive trip sections to hide (make invisible + height 0)
all dives that aren't in the selected trip.
I'll admit that this was much easier than I expected it to be.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way warning icons and tank change icons and other event markers are no
longer ridiculously tiny on retina screens. Oddly this doesn't appear to be
needed on Android, only on iOS.
Fixes#1033
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way even on smaller screens both email and password should fit
above the keyboard which makes data entry so much easier.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user goes to the credentials screen, they likely want to edit
something. So put the focus on the first entry field and show the
keyboard.
We also need to hide the keyboard when the credential screen becomes
invisble so that the keyboard doesn't stay around when the dive list
is shown.
Suggested-by: Henrik Brautaset Aronsen <subsurface@henrik.synth.no>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In the context of the mobile app this simply makes no sense. If the user
doesn't select this option, the app doesn't really work. So why have the option
in the first place?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Can't believe I didn't notice them earlier... I must have stared at these
strings countless times.
Reported-by: Scott Ireland <scott@sdj.ca>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Especially when showing the dive details and editing dive details,
having the option to go back in the context menu is nicer on iOS.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We received suggestions from users to darken the text color in the dive
list a bit and this does seem to be a lot more readable. Especially since
people are likely to use this outdoors the higher contrast seems
reasonable.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user tapped on the "Cloud credentials" menu and wants to go back to the
dive list (by selecting that option from the menu), allow them to do so if they
previously had valid credentials.
This allows them to go back to the dive list even on a device without a back
button like an iOS device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is so obvious... and I know others asked for this before. Should
definitely have been in the first version...
Fixes#1026
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user requests a refresh we always try to access the cloud and need to
show the notification accordingly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way we shouldn't have a drawer or other changes to the UI prevent the
user from seeing / interacting with the notification.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
[Dirk Hohndel: slightly changed to make it easier for translation plus
added one missing string that needed to be marked]
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We parsed it correctly, but then compared the permille values against
percent thresholds. What a stupid bug.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This implements a bunch of standard date and time formats, hoping that
what the user entered matches one of them.
I guess in the end we need to find decent calendar/clock based widgets to
enter the time and avoid the whole parsing hassle.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of having the notification disappear after five seconds, keep it
visible until we are done accessing the cloud. That seems to be more
intuitive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is turning into the never ending story. The documentation is not helpful,
so this is the result of a ton of trial and error - and I worry that the next
device I try this on will once again break things.
I think the scaling may finally be correct. Take the viewport rectangles
of the profile and the painter, create their ratio, multiply in the device
pixel ratio and the scene size with a little margin added around it.
But the other magic (especially the shifting of the profile on the
painter) makes absolutely no sense to me.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This allows us to use the single manager object to keep track of the dpr of the
screen and to pass it on if it changes (or when it first becomes known).
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is hard coded in version.cmake for now. The intent is to go to 1.0 in
the first release version and to increment from there whenever we create
an update.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the current release candidate of Qt 5.6.0 we get into an infinite
recursion of the grid layout engine. This had happened before (prior to the 5.6
beta) and it appeared that setting the maximum width of the columns was
sufficient to fix this. But with the RC even that isn't sufficient, so now we
give up on having QML figure out the best possible column width and hard code
both preferred and maximum width to the same, predefined values. That's a total
shame, but at least now we can build against Qt 5.6 without infinite recursions
and crashes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
don't create a local PassiveNotification copy,
use the global show/hidePassiveNotification from
ApplicationWindow, now that it works
Signed-off-by: Marco Martin <notmart@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
All error cases need to reset it as well.
And it's easier to reset it right after we come back from parse_file()
instead of trying to track all the exit cases after that.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And hide the notification either after 5 seconds or once we are done.
This requires an extension to the Kirigami components that isn't upstream,
yet.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Oops, I forgot to take the sort model on top of the model into account.
Now everything should stay consistent - ListView order when accessed from
QML, but internal order when accessing the underlying array.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
