When changing the theme to a dark theme, also change the
statistics theme. The code is a mess, because it crashes
when setting the theme right at the beginning. Therefore,
there is a "theme has been set" flag. Also, this directly
accesses the ThemeInterface singleton object. I have no
time to fight QML, sorry.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Global variables are evil. In this case not a problem, since
this is a singleton anyway. However, it is bad style and does
unnecessary thread synchronization.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Move the various font objects the the StatsTheme structure to enable
different font weights for different themes.
For the dark theme, switch to a bold font, because the thin white
font was barely visible.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Create the themes only when needed (singleton pattern). If
the themes should do more than colors, such as for example
fonts, it is not clear whether that can be done before main()
runs. By creating the themes on demand, the Qt UI should
be initialized in the constructors of the themes.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Some of the colors (like the bin colors or the highlight yellow) stay
the same, others are adjusted to fit better with a dark background.
This is far from perfect, but it's ok-ish.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
To enable rudimentary theming, collect all colors in a new
theme class. The class has to be passed down to the various
items.
In general the items save a reference to the them in the
constructor. Alternatively, they might also just query
the StatsView everytime they need to access a color.
For now, it's hard the say what is preferred: a reference
per item or a function call per invokation?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
These were leaking. Instead register them as global objects,
so they will be deleted on exit.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
We have a prevailing problem with global QObjects defined as
static global variables. These get destructed after main()
exits, which means that the QApplication object does not
exist anymore. This more often than not leads to crashes.
In a quick search I didn't find a mechanism to register
objects for deletion with QApplication. Therefore, let's
do our own list of global objects that get destructed
before destroying the QApplication.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
As of today, GitHub no longer allows the 'git://' protocol, so we need to
switch the submodule and our other references to cloning git repos to
'https://' instead.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Hirsute is EOL, so we need to move to Impish.
Adding Fedora 35 allows us to do a simple test against Qt 6.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Need to save the current dc as a member variable so we can apply redo
and undo to the correct dc later.
Signed-off-by: Michael Andreen <michael@andreen.dev>
Now this one was strange:
The ruler items keep a copy of the plot_info struct. However,
only a shallow copy is made (the actual plot data is not copied).
This means that the data is only valid as long as the source
plot_info is valid. But if that is guaranteed, we simply can
keep a pointer instead of the full object.
I wonder if it wouldn't be better still to keep a pointer to
the profile and query that for the plot info?
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The only things in display.h were profile related, so the
split between these two files is not comprehensible.
In fact profile.h includes display.h, because it needs the
struct defined therein. Let's just merge these two files.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The only caller misused this function to get access to the
current divecomputer. Remove it, since selection of the
current divecomputer is handled by the MainWindow.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There were only three users of that. For now do it inline, but
we may think about a separate function, which is only available
on desktop.
Moreover, add nullptr-checks, even if they are not strictly
necessary.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The profile knows which divecomputer it is plotting. No point
in accessing a global variable (which isn't even defined on
mobile).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The dive was passed as an argument to update_event_name(), but
the divecomputer was derived from the global dc_number variable.
That makes no sense. Therefore, pass the dc_number as argument
and update the only caller (smtk-import).
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
split_divecomputer() is passed a dive and a divecomputer number.
However, it accesses the currently visible dc!
This would be a nasty bug if it werent for the fact that it is
called when placing an undo command and there it is passed the
current dive and divecomputer anyway.
Nevertheless, fix this.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
With all the recent changes, some of the previous assumptions about the scale
of items seem to be no longer appropriate. Now that we are showing the icons in
the profile again on device it's quite obvious that they were way too big -
clearly we don't need the special scaling anymore.
Also implement a suggestion from Berthold to get slightly smaller fonts and
finer structures in the profile on mobile devices. This scaling of the DPR
seems to work well in my tests.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This way they are available in both mobile and desktop version.
Without this, the icons weren't shown on iOS and Android.
Fixes#3214
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
CID 376698 was a false positive, but understandable.
It is very hard for Coverity to realize that current_dive
cannot be null if editedDive is not-null.
By replacing current_dive by originalDive, the alert
should go away, since the latter is not checked for null.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This dive contains logs from two dive computer, Garmin Descent MK2i and
Suunto Vyper Air. These dive computers each has a wireless pressure
transmitter connected to them, attached to different cylinders.
When downloading the dives, both of these pressure sensors get attached
to the first cylinder. This is correct for the Garmin sensor, but not
the Suunto sensor, which should be attached to the second cylinder. The
pressure graph doesn't reflect the measured SAC rate.
To fix this, make sure that the Suunto log is visible and then in the
Equipment tab ensure that the Sensors column is visible. In the field for
the 2nd cylinder it will say "Select one of these cylinders: 0", this
shows that there is a sensor attached to the first cylinder. Change this
text to "0" and press enter, now the sensor will be attached to the 2nd
cylinder and the pressure graph will now show the measured SAC rate for
this cylinder.
Signed-off-by: Michael Andreen <michael@andreen.dev>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Previosuly they always used index 0 for the active sensor, use
add_sample_pressure instead.
Signed-off-by: Michael Andreen <michael@andreen.dev>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
Add a column to the equipment table that shows if a sensor is attached to a
tank, or which sensors would be available to attach to a tank that currently
doesn't have a pressure sensor associated with it.
Changing the sensor assignement can be undone.
This column is hidden by default as this is a somewhat unusual activity.
Signed-off-by: Michael Andreen <michael@andreen.dev>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This file was so confusing: A tabwidget containing a layout
containing a tabwidget. This strange situation is probably
due to moving the multi-dive warning message.
Remove the file, there seems to be nothing of importance
in there. All the UI was moved to the individual tabs.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The UI was updated before storing the dive. This had a nasty
effect: the current dive was shown in the profile and if that
was a manually added dive, the DivePlannerPointsModel was
overwritten. Thus the planned dive couldn't be saved anymore.
There is a comment why the UI switch was done beforehand.
But in my tests, this didn't seem to be valid anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
From a user's perspective, the edit mode is not a different
application mode anymore. Therefore, don't change the background
of the profile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Currently, when the profile is in edit mode, the user can't
save, exit, plan a new dive and is requested to save the
current dive. However, this makes no sense anymore, since
the profile always switches to edit mode when showing a
manually added dive.
If the user has any unsaved profile changes, the usual
dirty checks of the undo-system apply.
Only show above behavior when in the planner. There it is
useful because, these are not included in the undo system.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
In ProfileScene::draw(), the divecomputer was calculated
thrice. Remove the two redundant calls.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The edit mode was hidden in a context-menu. With fine-grained
undo there seems to be no need to explicitly exit edit mode.
Therefore, always switch to edit mode when displaying a
manually added dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was always this weird asymmetry that the "maintab" widget
is one of the tabs itself, whereas the additional tabs were
treated as extra-widgets. Turn the first tab into explicit
source files to make the distinction between container and
content clear.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This only calls MainWindow::showProfile(), so simply call
that directly.
Moreover make two "public slots" private member functions,
since these were only called locally.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When the user undos/redos the profile should update even
when in edit mode. This is a bit more complicated than
anticipated:
1) We should not do the update when emitting an undo command
from the profile. But we *should* update if it is an undo
command from the maintab (change depth/time).
2) The divepointsplannermodel has to be reset. Side note:
the code is truly abysmal as it sends numerous changed-signals.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Place undo commands for every change of the profile, not
only on "saving". Move the edit-mode from the mainwindow
and the maintab to the profile widget.
This is still very rough. For example, the only way to exit
the edit mode is changing the current dive.
The undo-commands are placed by the desktop-profile widget.
We might think about moving that down to the profile-view so
that this will be useable on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
It is confusing when undoing a command and nothing happens
in the UI. Therefore, switch to the corresponding dive when
undoing/redoing a replan or profile edit.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
