We used to just find all services and connect the characteristics change
signal etc to them all, but we really only care about the actual
preferred service that we'll be using.
So move the qt ble signal connection to after we've selected the
preferred service that we will actually be enabling notifications on and
do the writes to.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
XMP is a media-metadata standard based on XML which may be used
across a variety of media formats. Some video-processing software
writes XMP data without updating the native metadata fields.
Therefore, we should aim at reading XMP metadata and give priority
of XMP data over native fields.
Pros:
- Support for *all* common media formats.
Cons:
- XML (complex, verbose, chaotic).
- Does not even come close to fulfilling its promise of being
well defined (see below).
Implement a simple XMP-parser using libxml2. Connect the XMP-parser to
the existing Quicktime/MP4 parser.
First problem encountered: According to the spec, XMP data supposed
to be put in the 'XMP_' atom. But for example exiftools instead
writes an 'uuid' atom with a special 16-byte uid. Implement both,
more options will probably follow.
Second problem: two versions of recording the creation date were found
1) The content of a <exif:DateTimeOriginal> tag.
2) The xmp::CreateDate attribute of a <rdf:Description> tag.
Here too, more versions are expected to surface and will have
to be supported in due course (with an obvious priority problem).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
A user reported problems with editing the Suit and DiveMaster fields.
Apparently, editing does not change the currentText. Without doing
a deeper analysis, simply use editText (a more proper fix might be
changing the currentIndex on editing).
(Parially?) fixes#1694
Reported-by: Mark Powell <mcpowell123@gmail.com>
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Changing the scale, it seems that the header of trips is not rescaled.
The reason for this is simple. That string does not use our manipulated
font but a different one. In fact, this is the only ocurrence on the
divelist that did not scale. However, other screens hardly rescaled at
all. All these will be fixed in seperate commits.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
After the work in the previous commit, it gets very simple to implement
font scaling. Just assign a the new desired font scale to the used
font metrics. The QML engine does all the work.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
By manipulation the used font pointSize property, we can dynamically
scale fonts and derived UI objects. At the same time, we have
some logic to determine the default font, its size, etc, for example
depending on screen properties. The scaling of the UI (and its font)
does not need to interfere with those defaults.
However, when we want to reset the pointSize, we alter the default, so
a backup of the default is needed. Ok, not al full backup, as the only
thing we like to manipulate is the pointSize, to which we want to be
able to return.
All this leads to this commit. A basePointSize property is added, that
is initialized from the default. Due to the binding logic of the QML
engine, it is not a classic initialization, but a binding between the
2 properties. We need to break that binding explicitly, so that
the original PointSize is always preserved.
In addition, a display of the new font property is added to the
developers theme test.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
This theme test display created a new local FontMetrics object, that
does not per definition correspond with the "global" font metric
as defined in main.qml. The fix is simple. Display the font theme
data based on the one and only font metric from main.qml
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
We use that in the mobile app to scale the whole app, as all sizes there
are relative to the default font.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
It seems the documentation is incorrect - unless you explicitly set the
ApplicationWindow font to the the Application Font (just writing this
down sounds so silly...), it doesn't actually work.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Disable the button for the currently selected DC.
This gives an extra visual hint of which DC is currently selected.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
To prevent stale data in the download DC path we need to clear the entire
qPrefDiveComputer.vendor() object when the user purges the used DCs.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
Since we now store the last used DCs in out preferences we can use the information
to pre-populate the DC selector.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
We used to just blindly pick "first" and "last" characteristic from the
preferred service, and that was stupid but happened to work for the dive
computers we supported. Note that for some of them, "first" and "last"
was actually the *same* characteristic, since it could be a single one
that supported both.
However, this first/last hack definitely doesn't work for the Mares
BlueLink BLE dongle, and it's really all pretty wrong anyway.
So re-organize the code to actually look at the properties of the
characteristics. I don't have a BlueLink to test with, but my EON Core
and Shearwater Perdix AI are still happy with this, and the code
conceptually makes a lot more sense.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This still doesn't do the right thing for BT/BLE connections on a Mac, but it
should work on Linux and possibly Mac.
We definitely need to figure out how to get the Mac to successfully connect back
to a BT/BLE device.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And remove some includes and defines that are not used any more after
removal of the GPS webservice code.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
Fix multiple run-time errors in connect call introduced in 504e912512.
1) Set the proper signature of the signal. 2) make the used slot
a real slot (so move it to the proper section in the header) and
3) set the proper signature for the slot.
Highly unlikely that normal users notice the runtime errors and
possibly unwantend behavior, as this all deals with the subtile GPS
service update threshold.
Signed-off-by: Jan Mulder <jlmulder@xs4all.nl>
We used to just pick the first non-standard service we found (with a
special case for the Heinrichs Weikamp dive computers that have an
actual registered standard service).
We then waited for that service to finish discovery, and started using
it.
This changes the logic to wait for _all_ services to finish discovery,
and then after that we pick the one we like best. Right now the rule
for picking a preferred service is the same one we had before, but the
difference is that we now have the full discovery data, so we *could* do
something better.
Plus this makes our debug messages a lot more legible, when we don't
have the mix of overlapping service discovery with the actual IO we do
to the preferred service.
NOTE! This doesn't much matter for most of the dive computers that we
currently support BLE for. They don't tend to have a lot of odd
services.
But at least both the Mares BlueLink and the Garmin Descent both have
multiple services and it's not obvious which one to use, and this will
make it not only easier to debug those, it will make it easier to pick
the right preferred service descriptor to use.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
This is not only much clearer (and smaller code), but it also lowers the
latency for the waiting, since we don't always wait for the full 100ms.
Get rid of the now unused "waitfor()" function that just unconditionally
waited for 100ms.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
process_dives() is used to post-process the dive table after loading
or importing. The first parameter states whether this was after
load or import.
Especially in the light of undo, load and import are fundamentally
different things. Notably, that latter should be undo-able, whereas
the former is not. Therefore, as a first step to make import undo-able,
split the function in two versions and remove the first parameter.
It turns out the the load-version is very light. It only sets the
DC nicknames and sorts the dive-table. There seems to be no reason
to merge dives.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We only store the address part of the connection name, so don't try to find an
exact match, try to find the sub-string.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
On macOS the first of the four DC buttons was highlighted for some reason.
Explicitly setting autoDefault to no solved that problem.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The straight forward code to update the currentIndex of the combobox doesn't
appear to work on macOS (but works fine on Linux). Calling the event loop and
then calling update afterwards seems very unintuitive, but it appears to fix
the issue in my testing.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The algorithm tries to keep the order of the buttons the same. So if a dive
computer was used that's already remembered, don't reorder the buttons. But if
a new dive computer is used, add it as the first one and move the others back,
potentially dropping the oldest one.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Simply create the buttons that can be used as shortcuts to previously used dive
computers. This isn't hooked up at all.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This does feel clumsy and complicated. This is a lot of special case
handling and a lot of boilerplate for something that really should be
quite simple.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We need to explicitly refresh the divelist when switching between
metric and imperial unit systems. Or the changes will not be visible until
we restart the app or scroll outside of what's in the current cache.
This will update both the divelist view and the dive profiles to show the new units.
Signed-off-by: Joakim Bygdell <j.bygdell@gmail.com>
In visit_on_node() in core/parse-xml.c the name is extracted into
a static buffer. There seems to be no need for this being static,
as the name is only passed to the entry() function which (hopefully)
does not store a reference to the name anywhere.
If it does, this would need a *big* *fat* comment.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The existing code creates a deterministic ID (not exactly "unique") in order to
help us avoid merge conflicts in git-storage mode. But as a side effect, if we
re-download the same dive twice from a dive computer that supports GPS (right
now only the Garmin Descent Mk1) we are guaranteed to create the same dive site
uuid when we do this. So when we download a dive - whether we will actually
*use* that dive later or not - we will be filling in the dive site information
with the data we got from the dive computer.
... and in the process we will be overwriting any data that was filled in
manually. The name of the dive site, but also possibly even the GPS of the dive
site (maybe the user decided to edit that using the map, because while the
automatically downloaded GPS data was "correct", maybe the user wanted to
change it to be the actual under-water location using the satellite data,
rather than the place where you started the dive or where you surfaced).
In order to avoid this collision, this patch just makes the libdivecomputer
download not use the dive time, but "time of download" for the dive site time,
and thus effectively generate a new uuid for every download.
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
