The current dc global makes no sense on mobile. Therefore,
move the logic of the currently displayed dive computer
to the profile widget and remove the dc_number global
variable.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Don't access the global current_dc, but pass it to the sensor and
tank-use delegates, when the current dive or dive computer changes.
The same pattern is already realized for the tank and weight models.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On selection change, pass down selection (including current
dive and dc) to the tab widgets. Ultimately, this should
remove access to global variables. A number of new accesses
are marked as TODO. They shall be removed in due course.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was very weird: a setSelection() call was always followed
by a selectionChanged() call, though sometimes in convoluted
ways. Notably, the formed was called by the DiveListView, the
lattern then by the MainWindow.
Let's just merge these two functions.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This tries to encapsulate the management of the current dive and
divecomputer in the selection code. The current dive is alreay
set by setSelection(). Add a new parameter to also set the
current divecomputer. If -1 is passed, then the current
computer number is remained. This will allow us to audit the code.
Because for now, the whole "current dive computer" thing seems
to be ill-defined.
This fixes a bug: the dive-computer number wasn't validated
when making a new dive the current dive. The new code has some
drawbacks though: when selecting a whole trip, the validation
will be called for all dives in the trip and thus the dive computer
number will depend on the dive with the lowest amount of dive
computers in the trip. This will need to be fixed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The parser API was very annoying, as a number of tables
to-be-filled were passed in as pointers. The goal of this
commit is to collect all these tables in a single struct.
This should make it (more or less) clear what is actually
written into the divelog files.
Moreover, it should now be rather easy to search for
instances, where the global logfile is accessed (and it
turns out that there are many!).
The divelog struct does not contain the tables as substructs,
but only collects pointers. The idea is that the "divelog.h"
file can be included without all the other files describing
the numerous tables.
To make it easier to use from C++ parts of the code, the
struct implements a constructor and a destructor. Sadly,
we can't use smart pointers, since the pointers are accessed
from C code. Therfore the constructor and destructor are
quite complex.
The whole commit is large, but was mostly an automatic
conversion.
One oddity of note: the divelog structure also contains
the "autogroup" flag, since that is saved in the divelog.
This actually fixes a bug: Before, when importing dives
from a different log, the autogroup flag was overwritten.
This was probably not intended and does not happen anymore.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
For reasons of symmetry (there is a is_manually_added_dc()
function), create a make_manually_added_dc() function.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The dive-site editing can be reached from two states: from the
dive view and the dive list view. It always jumped back to
the dive view.
Therefore, remember the state. Use a stack-like structure, so
that the feature can be used for the dive-site view as well.
This is a bit inconsistent, because for example the statistics
view does not remember the previous state and allows a direct
jump to a different state. That should be fixed at some point.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This used to be one of the tab-widgets, which was illogical
and caused confusion. Notably, erroneously clicking on the
tab header led to a reset of the dive selection.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The map listens to the reset signal by itself.
This avoids double reload of the map on open/close.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Making this simply depend on Qt5 or Qt6 was short-sighted as work on QtLocation
upstream continues. Instead break this out as its own option.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
The undo stack is only relevant to the dives that were loaded at the
time the command was executed. If a file is closed, by specifically
closing it or opening another file, then the undo commands will
reference dives that aren't available anymore. Clearing the undo stack
ensures that we don't crash or accidentally do some undefined
modifications to the currently open file.
Signed-off-by: Michael Andreen <michael@andreen.dev>
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>
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>
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>
The mode of the profile (profile, edit, plan) was set in
MainWindow and ProfileWidget. For consistency move the one
setProfileState() call from MainWindow to ProfileWidget.
This removes a direct access to the profile-view and
therefore improves encapsulation.
Also, clear the profile, when no dive is shown to remove
any potentially dangling references.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This was moved to the desktop version. Enter the profile in
the constructor. Somewhat surprisingly, this seems to work.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Create a new class that encapsulates the profile-widget UI.
This is called ProfileWidget, which might be confusing since
the actual display is called ProfileWidget2. However, the
plan is to rename the latter to ProfileView. After all, it
is also used to print and to show the profile on mobile.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The MainWindow::configureToolBar() function is called every
time plotCurrentDive() is called. Moreover, this is the only
time that it is called. We might just fold the former into
the latter.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The changes in commit 4daf687876 ("profile: remove [disable|enable]Shortcuts()
signals") resulted in us no longer enabling the shortcuts on the desktop (at
least on macOS where I debugged this). This placement of the call feels like a
bit of overkill, but at least it shouldn't be wrong.
Fixes#3293
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
This occurs upon importing dives for example via CSV.
Make sure the profile display is cleared when selecting
such a dive rather than showing a different dive.
Allow editing the profile for such a dive.
Signed-off-by: Robert C. Helling <helling@atdotde.de>
The ADD state is not used for adding dives since adding dives
was made undoable. Therefore, rename it to EDIT state, since
that is what it is used for.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This flag is handled directly by the profile code
since 2015 (000c9cc21c).
The function therefore can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The backend infrastructure will soon be able to support more than one
cloud server which automagically stay in sync with each other.
One critical requirement for that to work is that once a session was
started with one of the servers, the complete session happens with that
server - we must not switch from server to server while doing a git
transaction. To make sure that's the case, we aren't trying to use DNS
tricks to make this load balancing scheme work, but instead try to
determine at program start which server is the best one to use.
Right now this is super simplistic. Two servers, one in the US, one in
Europe. By default we use the European server (most of our users appear
to be in Europe), but if we can figure out that the client is actually
in the Americas, use the US server. We might improve that heuristic over
time, but as a first attempt it seems not entirely bogus.
The way this is implemented is a simple combination of two free
webservices that together appear to give us a very reliable estimate
which continent the user is located on.
api.ipify.org gives us our external IP address
ip-api.com gives us the continent that IP address is on
If any of this fails or takes too long to respond, we simply ignore it
since either server will work. One oddity is that if we decide to change
servers we only change the settings that are stored on disk, not the
runtime preferences. This goes back to the comment above that we have to
avoid changing servers in mid sync.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
We know the preference is never empty, so stop testing for this. But
don't maintain two different preferences with basically the same
content. Instead add the '/git' suffix where needed and keep this all in
one place.
Simplify the extraction of the branch name from the cloud URL.
Also a typo fix and a new comment.
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
When showing the "empty-state", the profile toolbar was
disabled. This was done via a "reverse" signal from the
profile to the MainWindow. Instead control the toolbar
in the MainWindow directly. Break out the plot-dive
functionality into a member function and there test
whether a dive is shown or not.
The signal makes no sense in the context of mobile
or printing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When switching to the "plan" or "add" (which should rather be
called "edit", by the way) mode of the profile, the "shortcuts"
for copy&paste, undo&redo, etc. are disabled. When switching
to "profile" mode, they are reenabled.
This was done in a most convoluted way:
- The MainWindow calls the set*State() function of the profile.
- The Profile emits [disable|enable]Shortcuts() signals.
- The MainWindow catches these signals and does the enabling
or disabling.
Not only is this very hard to reason about, it is also in
contradiction to the profile being part of the display layer.
Moreover, in editCurrentDive() the MainWindow disabled the
shortcuts itself, so this was all redundant.
For the sake of sanity, let's just move this logic to the
MainWindow, unslotify the [disable|enable]Shortcuts() functions
and make them private.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The dive handlers are only updated by signals. This means that
switching into edit-mode has to be done in steps:
1) initialize the DivePointsPlannerModel
2) switch profile mode
3) load dive into DivePointsPlannerModel
2) and 3) cannot be exchanged, or the dive handlers are not
initialized.
To avoid this sandwitching of profile- and model-initialization,
populate the dive handlers when switching the profile mode.
Thus, the profile can be switched into edit/plan mode when
the DivePointsPlannerModel is fully initialized.
This will be important in upcoming commits, when the initialization
of the dive is moved from the profile to the DivePointsPlannerModel.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Remove mainwindow-access from the planner, by setting
the profile to planner state in the owner of the profile,
viz. the MainWindow.
The MainWindow sets the application state to planner, so
it seems legit that it also sets the profile state.
This removes a further interdependency.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
So far the profile operated on the global displayed_dive. Instead,
take the dive to be displayed as a parameter to the plotDive()
functions.
This is necessary if we want to have multiple concurrent
profile objects. Think for example for printing or for mobile
where multiple dive objects are active at the same time.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
To remove global state, make the dive that DivePlannerModel
works on a member variable. Pass the dive in createSimpleDive()
and loadFromDive(). Moreover, this should pave the way to more
fine-grained undo in the planner. Ultimately, the planner
should not be modal.
Attention: for now, the dive must still be displayed_dive,
because of the convoluted way in which the profile and the
planner work on the same dive.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Both loadFromDive() callers were clearing the model before
calling loadFromDive(). Move the clearing into that function
since it makes no sense to load into a non-cleared model.
Apparently this changes the way that no-cylinder dives are
treated and the code in ProfileWidget2::repositionDiveHandlers()
must now explicitly check for that condition.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
This model is only needed when in plan mode. To enable multiple
profilewidgets at the same time (e.g. for the mobile app or
for printing), make the pointer to DivePlannerPointsModel a
member variable that is initialized at construction time.
Moreover, allow passing null as the DivePlannerPointsModel,
in which case planning will be disabled. This will be useful
for simple printing.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The application state is a desktop-only thing. The mobile UI
also has its application state, but that is something completely
different.
The last remaining user of the application state was to flag
whether the planner is active. Since this has all been
unglobalized, the ApplicationState structure can be moved
from core to the desktop UI. And there it can be made local
to the MainWindow class.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The TemplateLayout prints different dives depending on
whether the planner is active. Instead of accessing a
global variable, pass the status down from the MainWindow.
That's all quite convoluted, since there are multiple
layers involved.
On the positive side, the in_planner() function has now
no users an can be removed.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On first startup, use the splitter values suggested by Dirk:
Top/Bottom: 60/40
Info/Profile: 50/50
List/Map: 60/40
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
On state change, the splitters were completely emptied and
refilled. Instead try to reuse already existing splitter
slots. This reduces annoying flickering.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The memory management of the quadrant widgets is a total mess:
When setting the widget, the QSplitters take ownership, which
means that they will delete the widget in their destructor.
This is inherently incompatible with singletons, which must
not be deleted.
To avoid all these troubles, remove the widgets from the
QSplitters in the desctructor of the MainWindow. This of
course means that we now have to take care about deletion
of the widgets.
For local widgets use std::unique_ptr, for singletons use
a static variable that is deleted on application exit.
Sadly, for the map widget we can't use a normal singleton,
because the QML MapWidget's memory management is buggy.
Add a comment in the source code explaining this.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When in planner mode, don't allow the user to change the application
state. This brought us nothing but troubles and inconsistencies.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
There was the "application state", which decided what to show
in the "quadrants" and the "view state" which decided which
quadrant to show. These interacted in a hard-to-grasp way.
The "view state" is used to show the map or dive list in
full screen.
I simply couldn't get these two orthogonal states to interact
properly. Moreover the thing was buggy: If a quadrant was hidden,
the user could still show it, by dragging from the side of the
window, at least under KDE.
To solve these woes, merge the two states into a single
application state. If the widget of a quadrant is set to null,
don't show it. So the four "view states" are now "application
states" where three of the four quadrants are not shown.
This also changes the memory management of the widgets:
widgets that are not shown are now removed from the QSplitter
objects. This makes it possible that the same widget is
shown in *different* quadrants.
While writing this, I stumbled upon a Qt bug, which is known
since 2014:
https://forum.qt.io/topic/43176/qsplitter-sizes-return-0
When restoring the quadrant sizes there was a test whether
the quadrant size is 0. If that was the case, a default size
was set. This seems not to work if the widgets were recently
added. Since this test now always fails, make the quadrants
non-collapsible and thus guarantee that 0 is never saved as
a size.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
