Using the y coordinate of the component directly doesn't work if we use
the component inside other components. Instead we need to grab the
position relative to the flickable.
The comment about needing the function for this to work seemed dubious.
So for now I've removed that function and am setting the position
directly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Doing this check every time we get a 'pressed' signal for the input
field seems excessive. We really only need to check when the input field
gets focus - that's when the OS virtual keyboard might open and hide the
field the user wants to edit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It's entirely reasonable to use the component in a context where we
don't have a flickable. Simply don't try to reposition things in that
case.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This reuses the logic we implemented in the SsrfTextField.
Eventually we will need to clean up the inconsistent names for these
elements.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
By removing focus from all input fields we can ensure that we have the
correct data reflected when saving an edited dive.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of always showing info about the location, allow all data to be
captured in a more structured format - but only when the app is in
verbose mode.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
There's no point in doing that - we set the correct text and leave that
in the editText and displayText for the combo box. If the user uses the
drop down they can replace that. This works correctly for single people,
and for multiple people the drop down doesn't work at all, anyway.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When we start editing a dive the OS will open the virtual keyboard if
any of the input fields have focus (which they might get when we set
their content).
The explicit closing of the keyboard might be overkill, but also doesn't
appear to hurt.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This seems more intuitive. For editable combo boxes you need to tap on
the indicator, but for non-editable (readonly) ones, you can tap
anywhere and the dropdown is shown.
The code feels a bit clumsy, but seems to work in all cases.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
They always have a 10% darker background, and show a border if the combo
box has focus. This seems to look reasonably well in all situation we
use them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Getting the visual right is really hard. The anchors seem to mostly work,
but it still doesn't look exactly right, IMHO.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I was convinced that I had fixed this while working on this set of patches,
but apparently I didn't. This simply hardcodes good colors.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This never ever worked to trigger a profile update. The code is
nonsensical as we cannot access the QMLProfile in a model delegate this
way from outside the delegate.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The weird 'Component.onCompleted' always felt like the wrong way to do
this. Setting this directly from the model seems like the much cleaner
solution.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This actually created a recursive dependency - I didn't see any negative
visual effect, but lots of annoying warnings.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In reality I should make our TemplateComboBox capable of handling the
modifications needed here without yet another reimplementation. Maybe
I'll do that next. This at least makes things look right.
A couple of odd whitespace changes snuck in at the end.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Again, the fact that you basically need to completely reimplement the
ComboBox in order to change some colors is frustrating.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This is needed for the Export page.
And may I say for the record that it's rather surprising that in order
to change the color of one of those elements one ends up having to
completely re-implement them.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
While the text name is 'light primary color' it really has to be a dark
blueish color to fit with the theme.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This requires more changes to Kirigami, but with this we get dark
drawers (the menus that slide in from the side) in the dark theme.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We do theming very differently from what Kirigami intended. Mostly
that's because our code predates theirs. But also because Kirigami wants
and app to simply use an OS theme - whereas we want to be able to
provide different looks, independent from the OS theme.
Ideally we'd still use the existing methods to change the colors and
sizes of Kirigami UI elements, but for now this hack helps improve
readability of the title bar.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
In the dive list the rendering of the line ended up being subject to
rounding errors. With this change we ensure that the thin line is always
shown.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since switching to the mobile-models and removing grantlee,
DiveObjectHelper was demoted to a thin wrapper around string
formatting functions. The last user was removed in a previous
commit.
It was never a good idea, given QML's strange memory-management.
Let's remove it.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When editing a dive, a DiveObjectHelper of the unmodified dive
was created to compare the edited with the old values. Since
the DiveObjectHelper is used here only as a pointless wrapper
around the formatting functions, call these functions directly.
However, note that the code is in principle wrong since the
change to the mobile-models, which do not use the DiveObjectHelper.
The real fix would be to reload the data from the model to prevent
going out-of-sync with respect to the formatting routines!
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
