QGIS setting registry follow-up

[3nids]

QGIS Enhancement: QGIS setting registry follow-up

Date 2022/02/01

Author/contact/maintainer Denis Rouzaud (@3nids)

Version QGIS 3.26/28

Context

Thanks to the Grant Proposal #124 in 2020, a settings registry has been implemented into QGIS core:

• setting registry Settings registry (QEP 124) QGIS#42597
• introspection Settings registry (QEP 124) part two settings introspection QGIS#42860
• the migration of the core settings Settings registry (QEP 124) part three QGIS#42954

This is available since QGIS 3.20 and allows to statically declare settings and add them in a registry:

• no more typo errors
• sub-registries can easily be added (optional providers, plugins)
• introspection is possible in registries

Thanks to this foundation which is now in place, we propose now to migrate all the remaining settings and improve the way the user can set the value of the setting.

What will be done

Migration of the remaining settings

• the rest of the settings will be migrated to the settings registries
• a CI test will be be introduced to avoid usage of old API (QgsSettings) in any part of the code

Use the introspection in the advanced settings editor

Rather than looping through the keys of QSettings, we will use introspection to display all the settings in the advanced settings editor.

A dedicated section will be created for plugins settings. It will list settings:

• from the plugin sub-registries if they were added with the new API
• using the former key tree inspection (QSettings) for the remaining ones (since all current plugins are using this approach)

Explicit declaration of sections/prefixes

The sections/prefixes will be statically declared in the registries and reused in the constructors of the settings.
The prefix are used to classify settings in a tree. This is reused in the advanced settings editor to display the settings in a tree.
The advantages:

• avoid defining the section with plain literals (leading to potential typo errors)
• fulfill the original QgsSettings::Section goal to organize all the settings in a clear way (the complete key is defined only once)

This change will not be in-forced (settings could still be declared with '/section/sub_section/setting_name')

The sections will defined in each registry without any constraint on overlapping.

Sub-registries can use the settings prefixes defined in a parent registry.

Settings GUI editors

The idea is to provide a default widget editor for each of the settings type (a color picker for color, a spin box for integers, a combobox for enum, etc.).
These editors will then be used in the advanced settings editor.

These editors will be added:

• line edit for QgsSettingsEntryString
• textarea (one line for one string) for QgsSettingsEntryStringList
• checkbox for QgsSettingsEntryBool
• spin box for QgsSettingsEntryInteger (with min/max)
• double spin box for QgsSettingsEntryDouble
• color picker QgsSettingsEntryColor
• combo box QgsSettingsEntryEnum
  *checkable list QgsSettingsEntryFlags
• no widget is proposed for QgsSettingsEntryVariant (not used up to now)

A Python API will be offered, which will be very useful for plugins (which would replace https://github.com/opengisch/qgis_setting_manager).

Optional additions

Depending on time left or as a follow-up, these could be implemented:

• a tool to automatically populate an ini file out of current value or defaults (using introspection)
• a migration tool to migrate settings (rename, move, … such as migrating old R/G/B/A settings to proper color ones.)
• use of settings widget across the whole QGIS main option dialog
• extend the setting registry to work for project settings/properties

Backwards Compatibility

We provide full compatibility with former settings.

[anitagraser]

Hi @3nids. I'm working on wrapping up the 2022 grant programme. How is the progress on this project? Can you give me an estimate for the completion and final report? As you probably know, I'm collecting all final reports and summarizing them so everyone can read up on the results of the programme.

[3nids]

We are currently working on this, I think I will get things in by 10 days from now.

[anitagraser]

@3nids could you please share a link to the final report here? Thank you, Anita

[3nids]

Here is the report:

After some hard thinking, I have finally found a nice way to register settings in a hierarchical and organized way, without too much complexity in the API to actually use the settings.

The work can mainly be seen here PR qgis/QGIS#51295 with the proposed approach.
To have a clean approach, some keys have been renamed. There is a compatibility handling (both forward and backward).

The PR is actually a part of the original QEP (mostly the GUI part is missing).
The trade of scope reduction towards a cleaner approach for the settings is valuable to me.
The structured approach will mainly allow for an even cleaner representation of settings in the advanced editor and a more comprehensive knowledge of named groups of settings (such as WFS connections, GPS devices, …).

I commit to start implementing the GUI part during the HF in NL this spring.

The migration of the remaining settings will be done continuously from now on (whenever some code is touched).
The idea is that any new settings must be added via the new API, as stated in the developer documentation.