Settings registry qep124

[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.

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 by subclassing QgsSettingsEntry in the class of appartenance of the settings like this for QgsLayout.h:

struct Settings
{
  struct SearchPathForTemplates : public QgsSettingsEntryStringList
  {
    //                                                     Settings key,                     Section,           Default value,              Description,      ... Other metadata like limits, gui hints, ...
    SearchPathForTemplates() : QgsSettingsEntryStringList( "Layout/searchPathsForTemplates", QgsSettings::Core, QStringList(), QObject::tr( "Search path for templates" ) ) {}
  };
};

and used like this:

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

The declaration will be shortened with a macro:

QGS_SETTING_ENTRY_STRINGLIST( SearchPathForTemplates, QStringLiteral( "Layout/searchPathsForTemplates" ), QgsSettings::Core, QStringList(), tr( "Search path for templates" ) )

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

struct Settings
{
  QGS_SETTING_ENTRY_BOOL( LocatorFilterEnabled, QStringLiteral( "locator_filters/enabled_%" ), QgsSettings::Gui, true, tr( "Enabled" ) )
  QGS_SETTING_ENTRY_BOOL( LocatorFilterDefault, QStringLiteral( "locator_filters/default_%" ), QgsSettings::Gui, false, tr( "Default value" ) )
  QGS_SETTING_ENTRY_STRING( LocatorFilterPrefix, QStringLiteral( "locator_filters/prefix_%" ), QgsSettings::Gui, QString(), tr( "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]

Hello @elpaso and @nyalldawson , could you please take a look at this new proposed solution and let me know your thoughts? Thank you!

[3nids]

gentle ping @nyalldawson and @elpaso
Time is getting short for the grants, and we'd like to move on here.

[elpaso]

@3nids @domi4484 sorry for the delay.

I like the new approach.

I don't have time for an in-depth review so my only comment for now is that if you can avoid the macro: do we have an alternative (maybe a template)?

[domi4484]

Sorry I screwed up my git branch and opened a new clean pr here: #42597