Settings registry (QEP 124)

[domi4484]

As of Enhancement proposal #124 and as followup to closed pr #41830 the goals of this pull request are to make the usage of settings less prone to errors.
Sorry @elpaso and @nyalldawson I screwed up my git branch and had to close #42239

In this proposed solution a new class QgsSettingsEntry is introduced. One instance will correspond to a single settings entry (or key) in QSettings.

The idea is to declare settings as static members in the class of appartenance like this for QgsLayout.h:

struct Settings
{
  static const inline QgsSettingsEntryStringList searchPathForTemplates = QgsSettingsEntryStringList( QStringLiteral( "Layout/searchPathsForTemplates" ), QgsSettings::Core, QStringList(), QObject::tr( "Search path for templates" ) );
};

and used like this:

QgsLayout::Settings::SearchPathForTemplates().setValue( QStringList() << "/path1" << "/path2" );

For settings with a dynamic key a placeholder can be inserted in the key:

struct Settings
{
  static const inline QgsSettingsEntryBool locatorFilterEnabled = QgsSettingsEntryBool( QStringLiteral( "locator_filters/enabled_%" ), QgsSettings::Gui, true, "Enabled" );
  static const inline QgsSettingsEntryBool locatorFilterDefault = QgsSettingsEntryBool( QStringLiteral( "locator_filters/default_%" ), QgsSettings::Gui, false, "Default value" );
  static const inline QgsSettingsEntryString locatorFilterPrefix = QgsSettingsEntryString( QStringLiteral( "locator_filters/prefix_%" ), QgsSettings::Gui, QString(), "Locator filter prefix" );
};

and can be accessed providing the dynamic part of the key as argument:

QgsLocator::Settings::locatorFilterEnabled.setValue( it.value(), filter->name() );

The settings registry in this solution would be needed only for introspection and it is simply implemented as a list of QgsSettingsEntry instances. Each module or plugin would have his own registry and add the settings to the main registry on load/startup.

This approach is more flexible as the one proposed in pr #41830 as it permit to keep the key and section as they are now. No migration will be needed as result of this work. Nonetheless it addresses all the issues exposed in the QEP.

[domi4484]

@elpaso I removed the macro in favor of defining the settings as static members. The macro was also causing troubles on the sip part.

[3nids]

We propose to merge this PR as a first step, as it is much easier to review.
Remains for a follow-up PR:

• adding Python tests
• migrate settings in core (maybe not all)
• registry introspection
• add API to register registries, so that the core registry would be able to list all settings
• adding a short doc to the coding guidelines

[nyalldawson]

I will review over this weekend...

[nyalldawson]

Couldn't we skip all the exists checks here by instead returning the default value when value() is called and the setting doesn't exist?

[domi4484]

For the enable yes. For the other two i think it is not possible because for example filter->prefix() would return a different value for each subclass of QgsLocatorFilter. QgsSettingsEntry support only one default value passed to the constructor.
Maybe it would be possible to add a second paramete to value( dynamicKey, defaultValueOverride ) or similar. defaultValueOverride would be taken in place of the "normal" default value when is valid.

[domi4484]

Parameters to override the default value added in commit abb8e80

[3nids]

nice work, this looks really good.
some minor comments.

[3nids]

isn't an empty string already a value?
this will not cause an issue?

[domi4484]

This would be an issue if someone wants to just remove the dynamic part by replacing it with an empty string. I will change the check with isNull()

[3nids]

Finally there :) Thanks for the amazing job and great inputs!