Steps to reproduce:
0. Ensure Gtk+ is _not_ loading modules from any sources other than rc/.ini files. E.g. disable XSettings, gnome-settings-daemon, unset GTK_MODULES environment variable, etc.
1. Create file /etc/gtk-3.0/settings.ini with contents:
gtk-modules = unexisting-gtk-module
2. Run any Gtk+3.0 application

EXPECTED RESULT:
Gtk-Message: Failed to load module "unexisting-gtk-module"

ACTUAL RESULT:
Nothing. Gtk+ does not attempt to load the module.


It seems that Gtk+ will try to load modules from the GTK_MODULES env var, from the --gtk-modules argv and from XSettings/gnome-settings-daemon. However, loading modules from a settings.ini file, despite documented, is not currently working.

The reason seems to be a bug in gtksettings.c. Function "settings_update_modules" is never called. This function should be called when the ::notify signal for the "gtk-modules" property fires. The startup process goes like this:

1. gtk_settings_get_for_screen is called during gtk init. Since the settings singleton is not yet created, gtk_settings_init is called.
2. gtk_settings_init freezes ::notify signals
3. gtk_settings_init loads the various settins.ini files, but no ::notify signals are emitted
4. gtk_settings_init thaws ::notify signals. ::notify signals are now emitted for all changed properties including gtk-modules. However, the ::notify callback (gtk_settings_notify) will do nothing because settings->priv->screen is not yet set to anything.
5. After the settings object is constructed, gtk_settings_get_for_screen now sets settings->priv->screen.

settings.ini files are never parsed again, so the ::notify signal for gtk-modules is never sent again.

In gtk2, gtkrc files would be parsed AFTER construction, so settings->priv->screen was set when the ::notify signals were fired. So this may be a regression from Gtk3.0 times.