The compiler complained that we were passing a float to the
QFont::setPointSize() function, which expects an integer.
Solve this by using the QFont::setPointSizeF() function.
This might introduce a user-visible change, albeit very unlikely:
We now may set the point-size to a non-integer number.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The compiler complains that members were initialized out-of-order.
Even though this is not an issue here it is correct to emit a
warning, since only then it is guaranteed that the objects are
destructed in reverse-order with respect to construction.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some slots in QMLManager were not called from the outside, some
only directly from C++-code. Make the former private and the latter
public member functions.
The idea here is to document which functions are actually called
from the outside and which are called from QML or connected to
signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There appears to be no reason for two-phase initialization.
Let's keep things simple: let the constructor produce a
functioning object.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
According to the Qt-docs you *may* send the new values in the
NOTIFY signal of Q_PROPERTYs. However, since changes will lead
to a reevaluation of a whole expression, this argument will be
unused. All it does is make the code more verbose and brittle:
What happens if you send the wrong value?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have a singleton class ThemeInterface, which means that it
is global and exists only once. It's members are static, i.e.
also global. A message from the department of redundancy department?
In any case, that makes no sense. Let's just make these members
local to the class.
I would even rip out the whole singleton thing, since the object
is not accessed anywhere outside from QML. Let's keep it for now.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
An Android user might reasonably assume that they can use the back button to
close the global or context drawers. So act accordingly.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This should deal with the rather confusing 'No dive in dive list' shown
while loading and processing the dive list.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since apparently the header property of the ListView isn't reliably
making sure that our filter input line is visible, let's move the filter
header to be it's own visual element and manually manage the
relationship between that and the ListView.
The obvious idea was to anchor the ListView to the bottom of the
filterHeader, but that didn't work in my tests. So instead we are using
the topMargin to make sure that there is space to show the header.
Because this re-indents the whole filterHeader, 'git show -w' gives a
much better idea what this commit actually changes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of the crude and error prone bool, let's just use the right tool
for this job.
In order to avoid issues with a goto across a mutex boundary, this
slightly restructures the code in one place - 'git show -w' makes it
clear that this is really rather simple in its changes.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm suspicious that an issue that some people have seen around changes
not being saved is caused by our handling of alreadySaving.
When starting with Subsurface-mobile in no-autosync mode, we were able
to end in a scenario where alreadySaving was true, even though there
were no unsaved changes. And in that case no changes made during such a
session were saved unless the user forced a manual sync with the server.
This commit radically changes our approach to handling the flag. It
moves it right next to the actual calls into code that could modify git
storage, and ensures that the flag can never stay set.
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>
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>
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>
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>
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>
The git parser loads into the global dive table, even if it
is called indirectly via parse_file(). However, parse_file()
may be given a different table. Fix this by extending the
git parser state.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
While I remember some of the thinking that went into doing things this way,
the more I read the code, the less it makes sense to me.
This is a rather drastic step, but in reasonably extensive testing it seems
to work in every case that I tried.
That's rather embarrassing, actually.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When editing a dive on mobile we might have to create a new
dive site. That site is added to the global dive site table
in the undo command. However, the code in QMLManager created
the dive site with create_dive_site*() functions, which already
adds it to the table. The undo command then added the dive
site again leading to a hang of the application.
To solve this problem, create new alloc_dive_site*()
functions that do the same as create_dive_site*()
but do not add it to the table.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This seems to make more sense than to not select anything (which was the
previous behavior).
If the same connection is still available, select it again. Otherwise
pick the top connection (which is the right thing to do if the user has
just plugged in a USB device and refreshes the list -- that device will
show up as top entry).
Based on a suggestion by Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This makes sense because USB devices will only show up when connected,
while BT/BLE will get listed once they are paired, even if not currently
connected. So the higher likelihood of being the device a user is looking
for is for any USB devices that show up, so those should go first.
Suggested-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of relying on the std::vector staying unchanged and not freeing
its members, instead keep a copy of the object in our DCDeviceData class.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If the user tries to download from a device that he hasn't given the app
permission to read from, Android will pop up a dialogue asking for that
permission. With this after giving the permission we continue (well,
technically, restart) the download which is likely the expected behavior.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The usbRescan() code is smart enough not to duplicate entries that might
already be there. And with this the user doesn't have to manually tap
rescan if they didn't open Subsurface-mobile via the intent after a
device was plugged in.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way even if a USB device wasn't added through an Android intent, we
still have a way to scan for it and select it. This is especially
important in case a user has a cable that we haven't seen yet (i.e. with
a VID/PID that we haven't added to Subsurface-mobile), but that
nevertheless works with the android usb serial drivers.
This also makes the flow a little more logical / consistent when
deciding which connections to show.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This finally allows us to download from not just the first device, but specifically
the device that the user picks.
Passing the object through a void pointer is not nice - but since this traverses
C code other solutions (like passing an index into the list) seemed even worse.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This vastly simplifies our handling of devive information as we simply use
what is already in the descriptor. This way we do not duplicate information
about USB devices in the QMLManager.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If we explicitly open the download page after the use plugged in a USB
device, don't try to use guesses from the BT/BLE pairings to populate
the device/connection dropdowns.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This just removes broken code. That file select dialog is still just a very
strange idea and should be revisited at some point.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
