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>
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 goal here is to remove a dependency on displayed_dive.
While doing so, make the model more general and display any dc.
Pass in the dc of the current dive instead of displayed dive,
since all other tabs are already converted to show data of
the current dive. The QStrings are cached since we generate
them anyway, so we may just keep them. Thus, there is no
danger of the dc becoming invalid.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When connecting a model to the TableModel class, it would connect
clicking on an item to the remove() slot of the model.
This breaks the program flow implied by the undo code:
Ui --> Undo-Command --> Model --> UI
Moreover, the naming of the remove() slot is illogical, because
clicks can also have different effects, as for example in the
cylinder-table.
Therefore, move the connect() call from TableModel to the
callers. In the case of TabDiveSite, move the remove() function
from the model to the TabWidget, where it makes more sense.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Maintab is one of our most complex classes, and it's
something I'm not actually proud of. But it currently
works and the idea of splitting it was in my head for
quite a while.
This is the third or fourth tentative of splitting it,
and this time I let the most complex part of it untouched,
the Notes and Equipment tab are way too complex to untangle
right now on my limited time.
A new class 'TabBase' should be used for any new tab that
we may create, and added on the MainTab (see the new lines
on the MainTab constructor).
Also, Extra Info, Information, Photos and Statistics where
ported to this new way helping reduce the number of
lines and functions on the MainTab quite a bit.
Overall this is a step in the right direction for the future.
Signed-off-by: Tomaz Canabrava <tcanabrava@kde.org>
Signed-off-by: Dirk Hohndel <dirk@hohndel.org>
