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>
The user had to restart the application or manually change the filter
if they changed the flag.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Mark invalid dives in the dive list by striking them out
and rendering them with a grey color. The color-change is
not sufficient, because the default model delegate ignores
color hints if the item is selected.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The location information model is updated automatically by the
divelist-model and the undo commands. Therefore remove the
QMLManager::updateSiteList() function. We do have to keep
the locationListChanged() signal though, because the list
of dive sites is not exported via model/view but rather via
a Q_PROPERTY. We really should change that.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When the dive list is cleared or updated, the entries in the
divesite-model become stale and therefore the divesite-model
(with the actual name LocationInformationModel) also must be
updated. This was done manually in some parts of the code and
forgotten in others. Therefore, do it directly in the clear()
and reset() function of the dive list-model.
This might be a bit of a layering violation: why should one
model call into another if they are not in parent/child
relationship? However, this seems easier than introducing
a global "reset dives" function that coordinates the models.
Moreover, it does not appear 100% safe: if the clearing of
the divesite model causes accesses to the divelist-model,
they happen in the midst of a model reset and we had horrible
bugs with that kind of things. However, I don't think that
should happen.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The setData() function was used to edit the number of a dive.
However, that doesn't appear to be functional. Therefore, remove
the code. There is a context-menu entry "renumber dives" for that.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
