Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
// SPDX-License-Identifier: GPL-2.0
|
|
|
|
|
2019-06-08 11:38:31 +00:00
|
|
|
// The DiveListNotifier emits signals when the dive-list changes (dives/trips/divesites created/deleted/moved/edited)
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
|
|
|
|
#ifndef DIVELISTNOTIFIER_H
|
|
|
|
#define DIVELISTNOTIFIER_H
|
|
|
|
|
|
|
|
#include "core/dive.h"
|
|
|
|
|
|
|
|
#include <QObject>
|
|
|
|
|
2019-02-24 20:22:33 +00:00
|
|
|
// Dive and trip fields that can be edited.
|
2019-01-27 21:08:13 +00:00
|
|
|
// Use "enum class" to not polute the global name space.
|
|
|
|
enum class DiveField {
|
2019-02-11 14:34:43 +00:00
|
|
|
NR,
|
2019-01-27 21:08:13 +00:00
|
|
|
DATETIME,
|
2019-02-10 16:37:06 +00:00
|
|
|
DEPTH,
|
|
|
|
DURATION,
|
2019-01-27 21:08:13 +00:00
|
|
|
AIR_TEMP,
|
|
|
|
WATER_TEMP,
|
2019-04-30 10:42:33 +00:00
|
|
|
ATM_PRESS,
|
2019-03-20 20:46:58 +00:00
|
|
|
DIVESITE,
|
2019-01-27 21:08:13 +00:00
|
|
|
DIVEMASTER,
|
|
|
|
BUDDY,
|
|
|
|
RATING,
|
|
|
|
VISIBILITY,
|
|
|
|
SUIT,
|
|
|
|
TAGS,
|
|
|
|
MODE,
|
|
|
|
NOTES,
|
|
|
|
};
|
2019-02-24 20:22:33 +00:00
|
|
|
enum class TripField {
|
|
|
|
LOCATION,
|
|
|
|
NOTES
|
|
|
|
};
|
2019-01-27 21:08:13 +00:00
|
|
|
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
class DiveListNotifier : public QObject {
|
|
|
|
Q_OBJECT
|
|
|
|
signals:
|
2019-06-23 07:22:26 +00:00
|
|
|
// Note that there are no signals for trips being added and created
|
|
|
|
// because these events never happen without a dive being added, removed or moved.
|
|
|
|
// The dives are always sorted according to the dives_less_than() function of the core.
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
void divesAdded(dive_trip *trip, bool addTrip, const QVector<dive *> &dives);
|
|
|
|
void divesDeleted(dive_trip *trip, bool deleteTrip, const QVector<dive *> &dives);
|
|
|
|
void divesMovedBetweenTrips(dive_trip *from, dive_trip *to, bool deleteFrom, bool createTo, const QVector<dive *> &dives);
|
2019-06-23 07:22:26 +00:00
|
|
|
void divesChanged(const QVector<dive *> &dives, DiveField field);
|
|
|
|
void divesTimeChanged(timestamp_t delta, const QVector<dive *> &dives);
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
|
2019-06-23 07:22:26 +00:00
|
|
|
void cylindersReset(const QVector<dive *> &dives);
|
|
|
|
void weightsystemsReset(const QVector<dive *> &dives);
|
2019-02-23 21:09:34 +00:00
|
|
|
|
2019-02-24 20:22:33 +00:00
|
|
|
// Trip edited signal
|
|
|
|
void tripChanged(dive_trip *trip, TripField field);
|
|
|
|
|
Undo: select dives after add, remove, merge, split dive commands
Select the proper dives after the add, remove, split and merge
dives commands on undo *and* redo. Generally, select the added
dives. For undo of add, remember the pre-addition selection.
For redo of remove, select the closest dive to the first removed
dive.
The biggest part of the commit is the signal-interface between
the dive commands and the dive-list model and dive-list view.
This is done in two steps:
1) To the DiveTripModel in batches of trips. The dive trip model
transforms the dives into indices.
2) To the DiveListView. The DiveListView has to translate the
DiveTripModel indexes to actual indexes via its QSortFilterProxy-
model.
For code-reuse, derive all divelist-changing commands from a new base-class,
which has a flag that describes whether the divelist changed. The helper
functions which add and remove dives are made members of the base class and
set the flag is a selected dive is added or removed.
To properly detect when the current dive was deleted it
became necessary to turn the current dive from an index
to a pointer, because indices are not stable.
Unfortunately, in some cases an index was expected and these
places now have to transform the dive into an index. These
should be converted in due course.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-03 09:35:43 +00:00
|
|
|
// Selection-signals come in two kinds:
|
2019-06-23 09:13:41 +00:00
|
|
|
// - divesSelected and currentDiveChanged are are used by the dive-list
|
2019-06-23 07:22:26 +00:00
|
|
|
// model and view to correctly highlight the correct dives.
|
Undo: select dives after add, remove, merge, split dive commands
Select the proper dives after the add, remove, split and merge
dives commands on undo *and* redo. Generally, select the added
dives. For undo of add, remember the pre-addition selection.
For redo of remove, select the closest dive to the first removed
dive.
The biggest part of the commit is the signal-interface between
the dive commands and the dive-list model and dive-list view.
This is done in two steps:
1) To the DiveTripModel in batches of trips. The dive trip model
transforms the dives into indices.
2) To the DiveListView. The DiveListView has to translate the
DiveTripModel indexes to actual indexes via its QSortFilterProxy-
model.
For code-reuse, derive all divelist-changing commands from a new base-class,
which has a flag that describes whether the divelist changed. The helper
functions which add and remove dives are made members of the base class and
set the flag is a selected dive is added or removed.
To properly detect when the current dive was deleted it
became necessary to turn the current dive from an index
to a pointer, because indices are not stable.
Unfortunately, in some cases an index was expected and these
places now have to transform the dive into an index. These
should be converted in due course.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-03 09:35:43 +00:00
|
|
|
// - selectionChanged() is called once at the end of commands if either the selection
|
|
|
|
// or the current dive changed. It is used by the main-window / profile to update
|
|
|
|
// their data.
|
2019-06-23 07:22:26 +00:00
|
|
|
void divesSelected(const QVector<dive *> &dives);
|
Undo: select dives after add, remove, merge, split dive commands
Select the proper dives after the add, remove, split and merge
dives commands on undo *and* redo. Generally, select the added
dives. For undo of add, remember the pre-addition selection.
For redo of remove, select the closest dive to the first removed
dive.
The biggest part of the commit is the signal-interface between
the dive commands and the dive-list model and dive-list view.
This is done in two steps:
1) To the DiveTripModel in batches of trips. The dive trip model
transforms the dives into indices.
2) To the DiveListView. The DiveListView has to translate the
DiveTripModel indexes to actual indexes via its QSortFilterProxy-
model.
For code-reuse, derive all divelist-changing commands from a new base-class,
which has a flag that describes whether the divelist changed. The helper
functions which add and remove dives are made members of the base class and
set the flag is a selected dive is added or removed.
To properly detect when the current dive was deleted it
became necessary to turn the current dive from an index
to a pointer, because indices are not stable.
Unfortunately, in some cases an index was expected and these
places now have to transform the dive into an index. These
should be converted in due course.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-03 09:35:43 +00:00
|
|
|
void currentDiveChanged();
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
void selectionChanged();
|
2019-03-10 15:03:39 +00:00
|
|
|
|
2019-03-11 23:25:31 +00:00
|
|
|
// Dive site signals. Add and delete events are sent per dive site and
|
|
|
|
// provide an index into the global dive site table.
|
|
|
|
void diveSiteAdded(dive_site *ds, int idx);
|
|
|
|
void diveSiteDeleted(dive_site *ds, int idx);
|
2019-03-10 15:03:39 +00:00
|
|
|
void diveSiteDiveCountChanged(dive_site *ds);
|
2019-03-12 22:51:39 +00:00
|
|
|
void diveSiteChanged(dive_site *ds, int field); // field according to LocationInformationModel
|
2019-03-20 20:46:58 +00:00
|
|
|
void diveSiteDivesChanged(dive_site *ds); // The dives associated with that site changed
|
2019-05-24 19:38:56 +00:00
|
|
|
|
|
|
|
// This signal is emited every time a command is executed.
|
|
|
|
// This is used to hide an old multi-dives-edited warning message.
|
|
|
|
// This is necessary, so that the user can't click on the "undo" button and undo
|
|
|
|
// an unrelated command.
|
|
|
|
void commandExecuted();
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
public:
|
|
|
|
// Desktop uses the QTreeView class to present the list of dives. The layout
|
|
|
|
// of this class gives us a very fundamental problem, as we can not easily
|
|
|
|
// distinguish between user-initiated changes of the selection and changes
|
|
|
|
// that are due to actions of the Command-classes. To solve this problem,
|
|
|
|
// the frontend can use this function to query whether a dive list-modifying
|
|
|
|
// command is currently executed. If this function returns true, the
|
|
|
|
// frontend is supposed to not modify the selection.
|
|
|
|
bool inCommand() const;
|
|
|
|
|
|
|
|
// The following class and function are used by divelist-modifying commands
|
2019-01-27 21:08:13 +00:00
|
|
|
// to signal that they are in-flight. If the returned object goes out of scope,
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
// the command-in-flight status is reset to its previous value. Thus, the
|
|
|
|
// function can be called recursively.
|
|
|
|
class InCommandMarker {
|
|
|
|
DiveListNotifier ¬ifier;
|
|
|
|
bool oldValue;
|
|
|
|
InCommandMarker(DiveListNotifier &);
|
|
|
|
friend DiveListNotifier;
|
|
|
|
public:
|
|
|
|
~InCommandMarker();
|
|
|
|
};
|
|
|
|
|
|
|
|
// Usage:
|
|
|
|
// void doWork()
|
|
|
|
// {
|
|
|
|
// auto marker = diveListNotifier.enterCommand();
|
|
|
|
// ... do work ...
|
|
|
|
// }
|
|
|
|
InCommandMarker enterCommand();
|
|
|
|
private:
|
|
|
|
friend InCommandMarker;
|
|
|
|
bool commandExecuting;
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
};
|
|
|
|
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
// The DiveListNotifier class has only trivial state.
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
// We can simply define it as a global object.
|
|
|
|
extern DiveListNotifier diveListNotifier;
|
|
|
|
|
Dive list view: replace signal-magic by flag
In DiveListView, we have a very fundamental problem: When
On the one hand, we get informed of user-selection in the
DiveListView::selectionChanged() slot. This has to set the
correct flags in the C-backend.
On the other hand, sometimes we have to set the selection
programatically, e.g. when selecting a trip. This is done
by calling QItemSelectionModel::select().
But: this will *also* call into the above slot, in which
we can't tell whether it was a user interaction or an
internal call. This can lead to either infinite loops or
very inefficient behavior, because the current dive
is set numerous times.
The current code is aware of that and disconnects the
corresponding signal. This is scary, as these signals are
set internally by the model and view. Replace this
by a global "command executing" flag in DiveListNotifier.
The flag is set using a "marker" class, which resets the flag
once it goes out of scope (cf. RAII pattern).
In DiveListView, only process a selection if the flag is not
set. Otherwise simply call the QTreeView base class, to reflect
the new selection in the UI.
To have a common point for notifications of selection changes,
add such a signal to DiveListNotifier. This signal will be
used by the DiveListView as well as the Command-objects.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-08-01 17:23:43 +00:00
|
|
|
// InCommandMarker is so trivial that the functions can be inlined.
|
|
|
|
// TODO: perhaps move this into own header-file.
|
|
|
|
inline DiveListNotifier::InCommandMarker::InCommandMarker(DiveListNotifier ¬ifierIn) : notifier(notifierIn),
|
|
|
|
oldValue(notifier.commandExecuting)
|
|
|
|
{
|
|
|
|
notifier.commandExecuting = true;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline DiveListNotifier::InCommandMarker::~InCommandMarker()
|
|
|
|
{
|
|
|
|
notifier.commandExecuting = oldValue;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline bool DiveListNotifier::inCommand() const
|
|
|
|
{
|
|
|
|
return commandExecuting;
|
|
|
|
}
|
|
|
|
|
|
|
|
inline DiveListNotifier::InCommandMarker DiveListNotifier::enterCommand()
|
|
|
|
{
|
|
|
|
return InCommandMarker(*this);
|
|
|
|
}
|
|
|
|
|
Dive list: implement proper Qt-model semantics for DiveTripModel
Previously, each dive-list modifying function would lead to a
full model reset. Instead, implement proper Qt-model semantics
using beginInsertRows()/endInsertRows(), beginRemoveRows()/
endRemoveRows(), dataChange().
To do so, a DiveListNotifer singleton is generatated, which
broadcasts all changes to the dive-list. Signals are sent by
the commands and received by the DiveTripModel. Signals are
batched by dive-trip. This seems to be an adequate compromise
for the two kinds of list-views (tree and list). In the common
usecase mostly dives of a single trip are affected.
Thus, batching of dives is performed in two positions:
- At command-level to batch by trip
- In DiveTripModel to feed batches of contiguous elements
to Qt's begin*/end*-functions.
This is conceptually simple, but rather complex code. To avoid
repetition of complex loops, the batching is implemented in
templated-functions, which are passed lambda-functions, which
are called for each batch.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
2018-07-30 07:20:25 +00:00
|
|
|
#endif
|