We don't have a tooltip on the QML UI as it's rendered into a pixmal.
We also don't need the timer as we don't need the TTS calculations.
And we don't need the acrobatics to figure out if we're in the planner as
we don't support the visual planner (or any planner, at this point) with
the mobile UI.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
If things go as planned, then the length of the polygon is the same as the
number of rows in the model. Turns out when running Subsurface-mobile on
Android that simple truth doesn't seem to be correct. Most of the time
the polygon seems to have twice as many elements as the model. But a few
times I ended up in here with a polygon that had fewer elements than the
model. And then things crash.
This simply avoids the crash.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Now that we have the possibility to add images without meaningful
time stamps to a dive, we should let the user provide that time
offset manually. This patch allowed pictures to be dragged from
the image list to the profile.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The "Print" button in the planner dumps the QTextEdit to
a QPrinter via ::print(). This patch renders the Profile
to a Pixmap which is inserted as Base64 stream in an <img>
tag and fed on top of the QTextEdit HTML contents.
This route preserves the planner notes as text in PDF prints.
The quick alternative is to render the QTextDocument to
a QPixmap as well, but that will not preserve the text
and pagination becomes manual.
Possibly the QTextDocument can be rendered as a QPicture
but pagination is still an issue, while so far there is exactly
one user requesting this feature!
Related small change in ProfileWidget2:
Explicitly hide the tooltip when printMode is true.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This fixes a bunch of warnings in the mobile version where these slots
are not defined (see the corresponding header's conditionals).
Signed-off-by: Sebastian Kügler <sebas@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When the tooltip is expanded, not enough padding is present right
from the text and bottom from it, making the tooltip border
appear very close to the text.
When the tooltip is collapsed (no time entries) it clips
the graph/pixmap which makes the graph bottom left corner appear
to be outside of the tooltip, mainly because of the white border
of the tooltip background and the background rounding.
To prevent these visual artifacts and to prettify the tooltip
this patch:
- makes the rounding 8 instead of 10 of the background rectangle
- doubles the padding left and right from the pixmap
(the above two pretty much move the pixmap bottom left corner
away from the rounded bottom left edge of the tooltip background)
- add more padding right and bottom from the text
- never reduce the height of the tooltip to be smaller than
the graph/pixmap height.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
DiveCalculatedCeiling is the last class the references
MainWindow in the profile-widget stack.
In modelDataChanged() it looks for the information()
widget and sets a slot for the dateTimeChanged() signal that
information() emits.
To solve the issue we make DiveCalculatedCeiling recieve
a ProfileWidget2 reference and make ProfileWidget2 emit
the dateTimeChangedItems() signal.
ProfileWidget2 itself listens for the dateTimeChanged()
signal that information() emits and emits dateTimeChangedItems()
to notify any possible children/item listeners in the
ProfileWidget2::dateTimeChanged() slot.
The connection between ProfileWidget2 and information()
is set in MainWindow. This makes DiveCalculatedCeiling
unaware of MainWindow and which class originally emits
the dateTimeChanged() signal to ProfileWidget2.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
--
Think delegation.
Tomaz, please take a look at this one, to double check
if i messed up.
also i have zero idea how the mobile app is setting these
connections, if it does so even.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
things like:
potentially, for every item interested in 'printMode'
can clutter the profile-widget stack a lot.
instead the items should be aware of the profile widget
instance and not MainWindow.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
DiveCartesianAxis and derivatives can recieve
ProfileWidget2 as an instance in their constructor.
Signed-off-by: Lubomir I. Ivanov <neolit123@gmail.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Since we don't support printing in subsurface-mobile this solves the
problem at hand - but it doesn't do what we really want which is to
untangle the Profile from the MainWindow.
Partial credit.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
And action can't not just trigger a slot, it can also send a signal.
With this there is no reference to the MainWindow left in the profile.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Ummm. What? That one was awesome. This seems easier :-)
MainWindow::instance()->graphics() is a way to retrieve a pointer to the
profile widget...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I don't quite know why these were parented to the MainWindow - I bet
there's a very clever reason that I'm missing...
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Instead of directly calling into the MainWindow, redirect this via a
signal so Subsurface mobile can hook it up as needed.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
I'm not sure we can ever run into this issue anymore since we stop
calculating TTS / NDL past 2 hours, but I guess on a fairly slow CPU this
still could take too long.
But instead of calling into MainWindow let's just change the setting right
here and add a signal to show the notification - that way we can use the
appropriate way to make such notifications on the mobile app.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The new preferences dialog still needs a bit of fine tuning
but should already work.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The reason for that is, even if profile widget is made with qpainter
and for that reason it should be a desktop widget, it's being used
on the mobile version because of a lack of QML plotting library that
is fast and reliable.
We discovered that it was faster just to encapsulate our Profile in
a QML class and call it directly.
Signed-off-by: Tomaz Canabrava <tomaz.canabrava@intel.com>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
