With this, international Portuguese, Swedish, Finnish, Hebrew, Spanish,
Romanian, Dutch, and German are 100% translated.
Catalan, Chinese, and Bulgarian are more than 90% translated as well.
A HUGE thank you to the translators once again stepping up.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is a feature that I never fully understood, but that apparently is
causing the drawers to show up for people who are just trying to
interact with the action button. The approach here is really drastic and
crude, but in my testing it seems to work.
Reported-by: Hartley Horwitz <hhrwtz@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This was disabled in the past because it was deemed to slow. A lot
of time has passed, since. Maybe on current phones / iPads this is
acceptable again?
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This adds a context menu entry for top level dives that allows the user
to create a trip for that dive.
Unfortunately this creates a new string to translate right before a
release...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we start adding a dive, we actually create a diveAdd undo command
so we have a dive that the user can edit. Which means we need to undo
this action if we cancel.
Also, for a more consistent UI, we should pop the dive details page that
we used to edit this dive and bring the user back to the dive list.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We still used pageStack.push() all over the place.
Also, in showPage, disable the map hack if the user actively picks a
different page.
This should fix an issue where the user picked the map and then tried to
add a dive to the dive list - and instead of the dive edit was shown the
map again.
Reported-by: Hartley Horwitz <hhrwtz@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's possible for our code to think that the user wants to pan the
profile before realizing that the user actually is making a pinch
gesture. In that case the profile could get stuck in semi-transparent
mode. This prevents that from happening by explicitly resetting the
opacity to 1.0 when we start a pinch.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user is scaling out again we need to make sure that our offsets
are adjusted so that we always show a subset of the profile and not
'empty space' outside of it. Instead of reimplementing the offset logic,
let's just trigger another paint() call.
This requires a trampoline function because of different signal and slot
signatures.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When zooming and panning the profile, make sure we always show a subset
of the profile and don't end up showing the empty space outside of the
profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And allow touchpad gestures to be recognized as well. This has no
negative impact on the mobile platforms, but makes it much easier to
test profile scaling / panning on the desktop.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
To mark invalid dives, we use a struck-out font, which was a static
variable at translation unit scope, i.e. initialized at application
startup. Sadly, this crashes on iOS.
It is unclear when we can initialize fonts. Try to move initialization
to the constructore of DiveTripModelBase and make the font a member
of that class. For consistency, also make the invalidBrush a member
of this class.
This now means that the diveData function cannot be static anymore,
since it needs access to the font and brush. But OK.
Reported-by: Dirk Hohndel <dirk@hohndel.org>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This way someone trying to swipe from dive to dive won't inadvertantly
pan the profile instead. And panning it really only makes sense when
zoomed in in the first place.
This could leave us in a situation where we zoom in, pan, zoom out and
now the profile is out of whack and we cannot correct it. A simple click
on the profile fixes that.
The real solution would be some constraining / adjusting as we zoom and
pan to ensure we keep things correctly positioned. Maybe I'll figure out
the correct way to do this later...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I would love to figure out a way how to bundle the user manual and load
it from the device file system, but in the meantime this should continue
to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While this is based in large parts on the existing manual, it is a fairly
substantial rewrite with mostly new screenshots.
Includes edits by Rainer Mohr.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
With the change in context for all the commands there was a lot thrash
in the translations. I tried to work around that as well as I could and
to keep the translations valid on Transifex, but a few appear to have
been lost in the shuffle.
But at least the command texts are now correctly translated.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The way inheritance is implemented for the undo commands confuses the Qt
translation tooling - with the result that the context assumed by the
tools used to extract the strings doesn't match the context calculated
at runtime - so all the translations for the strings in undo commands
fail (including creating proper numerus forms).
This change forces a consistant context tag, at the price of creating a
significant delta for the source strings (the strings themselves stay
the same, but the context for a lot of them changes). I am hoping that
Transifex is smart enough to automagically add the correct translations
for these, but I guess I won't know until I try.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This had been something I did manually which caused all kinds of
mistakes. I finally figured out how this is supposed to work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is pointless bike-shedding: instead of allocating the QTranslators
on the heap an assigning them to a variable at translation-unit scope,
we can simply generate them as static objects.
That makes
1) two fewer lines of code
2) the translator-resources are properly released when the application
closes.
Not that either of these points would make *any* difference.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The prefs.locale.lang_locale field was overwritten without
free()ing the old value. Not that the function would be called
numerous times, but as a matter of principle...
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The uiLanguage() function was used for two purposes: to initialize
the language related preferences and to read the current language.
To make things more easy to follow, split this function in two:
one for initializing, one for getting the current language.
Moreover, don't return the current locale in an out-parameter
as there is already a function to do that [getLocale()].
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In uiLanguage() the preferences fields are initialized and there
is fixup for a MacOS indiosyncrasy. For some reason the uncorrected
value is written to the preferences. Let's store the corrected
value instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
uiLanguage() initializes the language fields from the preferences
values. It is unclear why this function is called in qPref::loadSync()
*before* the fields are loaded from disk. It can only initialize to
the default values anyway. After qPref::loadSync() uiLanguage()
is called again so that everything can be initialized with the
correct perferences values.
Remove the first call. If things break, let's fix them in a sensible
way.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This reverts commit 573a4a5e2d.
The commit broke setting the language in the desktop preferences:
Instead of setting the locale in the prefs struct, the locale
is set via qPrefLanguage. However, that saves the default language
(extracted from the system) to disk. Now when the language is
read from the preferences, we get that default value.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The hardcoded widths with fixed values was just flat our broken and
created all kinds of strange artifacts.
But even with this somewhat more idiomatic approach this still isn't
perfect - on wider screens it doesn't shrink back to the minimum column
width. But that seems like a bit of a corner case. Overall this feels
like a huge improvement.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The number of possible sequences of events when the user is connecting a
USB device is rather surprising. These changes try to ensure that in
every case we get USB connection information we do in fact show the
correct (or best guess) connection.
See #2686
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Adding dives uses the number of the last dive to create a new
dive number. Ignore invalid dives.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
