subsurface.git/desktop-widgets, branch v4.9.8

desktop: minor tweak for dark modes

2020-11-07T23:23:53Z

This ensures that the BT/BLE devices are legible, regardless of light or dark mode. Signed-off-by: Dirk Hohndel

filter: don't escape '&' in filter-preset menu

2020-11-07T22:08:39Z

When constructing an action, '&' is used as the keyboard shortcut marker. Since this mangles preset names, use the setIconText() function of the action instead. Signed-off-by: Berthold Stoeger

filter: don't render filter preset name as HTML text

2020-11-07T19:37:51Z

QLabels must be explicitly set to not accept HTML input. Signed-off-by: Berthold Stoeger

desktop: fix saving of column-widths of device and site tables

2020-11-07T19:37:51Z

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

desktop: rename table widget in DiveComputerTab to "devices"

2020-11-07T19:37:51Z

The custom TableView widget saves the table width on destruction. For that, it uses the "objectName()". Since the table of the DiveComputerTab was simply called "table" in the UI file, the widths were saved in that generic section. To avoid future name-conflicts, rename the widget to "devices". Signed-off-by: Berthold Stoeger

desktop: maximize size of last column in filter-preset table

2020-11-07T19:37:51Z

This was just ugly: the column with the "trash" symbol and the name had the same size. On creation of the object, make the last column expand and adapt the size of the "trash" column according to its content. Signed-off-by: Berthold Stoeger

revert preference settings for title color

2020-11-04T22:51:55Z

Because of subsequent changes there is no clean way to just revert the changes introduced in commit 8b36cf1051 ("desktop: offer different colors for info tab titles"), so this manually removes the parts we don't need anymore. This also restores a tooltip value that was inadvertantly removed in that commit. Signed-off-by: Dirk Hohndel

desktop: automatically pick a good theme title color

2020-11-04T22:47:10Z

The preference setting seemed far too strange to do this. And not very user friendly. So instead we figure out if this is a dark theme or not by looking at text and background colors in the palette, and make sure we get notified if that changes. Signed-off-by: Dirk Hohndel

Reorganise the current statistics tab

2020-11-04T19:34:26Z

As the title above says.... Signed-off-by: willemferguson

desktop: generalize the colorization of the tab widget

2020-11-04T07:08:39Z

Instead of doing it just for the Information tab, do it for all of the tabs. There's still room for improvement. But this certainly feels more consistent. Signed-off-by: Dirk Hohndel