Qt's memory management scheme is completely broken and messes
with common expectations.
QObjects are organized as a tree. The children are destroyed
in the destructor of QObject. This means that they are destructed
after the destructor of the parent object has run and its
sub-object were destructed. Obviously, this makes no sense as
the child objects should be able to access their parent at
any time.
To restore the commonly expected deterministic order of
construction and destruction, one might simply do away with
Qt's silly object tree and organise things using classical
subobjects. However, that breaks with the Qt-generated UI
classes: The objects generated by these classes are *not*
destructed with the UI class. Instead, they are attached
to the widget's QObject tree. Thus these are again destructed
*after* the widget! Who comes up with such a scheme?
In our case this means that we cannot have models used for
TableViews as subobjects, because the TableView needs the
model to save the column widths in the destructor. Which,
as detailed above is called *after* the desctructor of the
widget! Thus, turn these models into heap-allocated objects
and add them to the QObject tree.
Funilly, this exposes another insanity of Qt's QObject tree:
Children are destructed in order of construction! One would
expect that if objects are constructed in the sequence
A, B, C one can expect that C can, at any time, access B and A.
Not so in Qt: The destruction order is likewise A, B, C!
Thus, take care to init the widgets before the model. Jeez.
Finally, print a warning in the column-saving code of
TableWidget, so that these kind of subtleties are caught
in the future.
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>
This one-liner was called in only one place from the same class.
Just fold it into the caller.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The dive-site-edit and dive-site-table tabs both put the filter
into a special dive-site mode. When switching between both, it
could happen that the one got its show befor the other got
its hide event.
Thus, the first would start dive-site filtering and the second
stop it. Now the app was not in filter mode even though it should.
To solve this problem, add reference counting for the filter's
dive-site mode. In both tabs call the enter/exit functions
on show/hide. In the dive-site-table tab, when the selection
changes, use a set function that doesn't modify the reference count.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When in dive site tab and some dive sites are selected, show only
dives at those sites. Simply read the selection and pass it to the
filter.
Start and stop filtering when switching to and from the tab,
respectively.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a "purge unused dive sites" button to the dive site list.
Connect it to a new PurgeUnusedDiveSites command. Implementation
was trivial: simply copy the DeleteDiveSites command.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
If the name of a dive site is edited, it might wander somewhere
else in the table and thus out of view. Hook into the "dive site
changed" signal and scroll there.
The code is rather subtle as it depends on signals being called
in a certain order: First the item is moved in the model, only
then can we scroll to the correct place.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
When adding a dive site, enter the name field of the new dive site.
Thus, when adding a new dive site, the user can immediately edit the
name.
The code is rather subtle: It hooks into the dive site added signal
before executing the command and unhooks afterwards. This only works,
because signals are executed in order of connect - thus the model
adds the index first and only *then* is the field edited.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Implement a dive site addition undo command and connect it to
the add dive site button. The added dive site has a default
name ("new dive site").
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
The LocationInformationModel used to sort its entries and was completely
rebuilt after every change. This makes it rather complex to support
incremental changes.
Instead, keep LocationInformationModel sorted by UUID so that indexes
are consistent with indices in the core dive site table.
Implement sorting by other columns than name and enable sorting in the
dive site view.
Finally, don't cache the list of dive site names for the mobile app,
since that would also need some rather convoluted methods of keeping
the list up to date. Calculate it on the fly.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
Add a very simple tab-widget presenting the list of known dive sites.
The table is rendered using our custom "TableView".
The (mis)uses the "LocationInformationModel". It moves the items
to be displayed (delete, name, description, number of dives) to the
front and makes the others hidden.
Moreover, it was necessary to limit the geo-tag decoration role to
the name to avoid having the icon next to each column.
Make the trash-can icon active and the name and description editable.
This is modelled after the cylinders-table code.
Signed-off-by: Berthold Stoeger <bstoeger@mail.tuwien.ac.at>
