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>
In edit commands, the fulltext might have changed and therefore
we have to update the fulltext index.
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>
The pop_cstring() function is used by the git parser to
duplicate a quoted string. On error, it returns an empty
string literal. Since the caller expects a copied string
and takes ownership of that string, it will ultimately
be freed.
Concrete example: a log with erroneous cylinder data was opened
getting such an empty string literal as description. On closing or
syncing with the cloud, the dive is freed, leading to a free
of the string literal -> crash.
Return a copy of the empty string instead.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This needs more work and especially new screen shots, but for now this
covers at least some of the most important changes.
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>
If the user hadn't granted USB permissions, yet, we asynchronously get informed
once they did that. This ensures that the user gets taken back to the download
page once they approve.
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>
Instead of creating a string with all the object information, simply pass
the actual object to the C++ code.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We now always create a list of usb devices that doesn't list a driver
for known devices, and adds multiple entries with each of the drivers
for devices that are unknown to us.
This removes some debugging output in the ..._open() function as well.
This could be combined with Christof's earlier commit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
For a small number of dive computers we can actually figure out the
real information which we can then later show to the user.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When a user is downloading from a DC for the first time (without using
the "usb device connected" popup), the user is requested to grant
permission to use the USB device.
This is done asynchronously, thus the download is aborted. To be more
user-friendly, we now react to the intent with the "usb granted" result.
The plan here is to start the download again.
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
As discussed in issue #2657, there are now more fields about the usb
device information in android_usb_serial_device_descriptor.
Additionally, the user-facing string now makes more sense:
"vendor [<bus# as integer>:<dev# as integer>]"
Where vendor is as reported by android, but shortened to 16 characters.
Examples:
FTDI [1:2]
Silicon Labs [1:4]
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Android takes some pretty hard measures to save power, including
shutting down the CPU. Since this can interfer with the download from an
usb serial device, we now use a wakelock to keep the CPU running during
download.
Signed-off-by: Christof Arnosti <charno@charno.ch>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This commit contains the serial_android_usb part of the changes proposed
in issue #2657.
What's implemented:
- A data structure that contains all the data that can be used to
describe an usb device (including user-facing string).
- A function to get a list of all attached usb devices (optionally with
selectable driver class).
- Changes in the serial_android_usb_open-function and in the Java part
to use the information about the usb device and optionally selected
driver when connecting.
This commit keeps compatibility with the current UI-Code in the case
that only one USB-Device is connected. If two devices are connected,
only the first one is tried.
There are still some small things to do:
- Change the user-facing string to something more descriptive.
- Parts which aren't uesd anymore when the UI-Part is implemented are
simply marked as obsolete (to keep compatibility for now).
But generally it seems to work.
[Dirk Hohndel: some white space / coding style adjustments]
Signed-off-by: Christof Arnosti <charno@charno.ch>
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 is the exact same case as the previous commit, just for the writing
side.
Once again, it's the subsurface rfcomm iostream code that can return
DC_STATUS_SUCCESS with a byte count of zero when something goes wrong
with the write.
And once again, our libdivecomputer iostream code didn't try to be
robust and protect itself from that case.
The fix is equivalent, although slightly simpler, since the write side
doesn't have the whole timeout issue.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
We had two independent bugs here, both of which needed to fire for this
to cause a problem. This fixes both of them.
The first bug was that our rfcomm code would return DC_STATUS_SUCCESS
with a zero-sized read when a timeout happened, or when the rfcomm
socket had disconnected. That makes absolutely no sense. We should
return DC_STATUS_TIMEOUT on timeout, and DC_STATUS_IO if the socket has
disconnected without any data.
The fix to this is to make the whole rfcomm iostream read logic much
simpler: there's no need to loop at all for partial results, because the
libdivecomputer iostream side will do the loop for us (and handle
partial results much better: it knows if the target backend can handle
those partial results or not).
The second bug was in our libdivecomputer iostream read() function,
which reacted very badly to this bad return value. This updates our
libdivecomputer branch to one that is more careful about things.
Reported-by: linuxcrash <albin@mrty.ch>
Debugged-by: Jef Driesen <jef@libdivecomputer.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
The diveListNotifier.divesSelected() signal is used to inform the
models of a selection change. It sent the current dive as a second
parameter. This is redundant, because the only sender of the signal
sets current_dive just before sending the signal. Remove the
parameter, which appears to be an artifact.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
