The wrapGAppsHook already adds dconf to the path. The interface works fine for me. What desktop environment/window manager are you running?

KDE 5.
I know that before explicitly installing dconf deja-dup did not work,and after it works normally,and I did install both via .config/nixpkgs/config.nix,so I think that it does need to be propagated

Interesting, KDE does not have any settings daemon. We would have to propagate dconf from all GTK applications. Or better yet, keyfile gsettings backend should be used instead. Not sure how to do that though. Edit: there is GSETTINGS_BACKEND environment variable.

Could we use propagatedUserEnvPkgs?

Also,as the dconf backend is the default,I expect that it is the one with less bugs,and I don't have problems in running it

Also,as the dconf backend is the default,I expect that it is the one with less bugs,and I don't have problems in running it

I would expect apps to use platform-specific backend, i.e. dconf on GNOME, registry on Windows and whatever on KDE.

Can this be integrated or no?

I am still not convinced this is the correct solution.

@jtojnar even if it were not the "correct" solution (by whatever mean you measure it) we can still use it as stopgap solution and then develop a more refined patch later

Yes, that is what I mean. If you are building a desktop environment yourself, you need to select all the components your applications will need. Another example is the secret agent issue: applications need some password manager to store their passwords, but if they added GNOME Keyring to the propagatedUserEnvPkgs attribute, people using the application in environments other than GNOME would not be very happy.

It would be nice if Nix could warn you when you have one of the components missing – for example, the package expression could contain requiredOptions = [ "programs.gsettings.enable" ]; and the module would assert that a backend is selected (though this would not work outside of NixOS)

Please merge this soon, I like having backups :|

gnome3.dconf is a system service that needs to be added to services.dbus.packages by your desktop environment. If you create your own environment, you will need to add it yourself (adding programs.dconf.enable = true; to configuration.nix should work). Nix does not contain a mechanism for representing a dependency on a service.