That’s not doable because that’d be meaningless. Applications read specific settings, so what would mean adding a setting manually at a different path?
Yes, there are in fact some reasons. Notably, applications could define things called “relocatable schemas.” What is called a “schema” in the GLib.Settings world is a description of a list of keys that an application uses; it has usually a fixed path, used by the backend (the “dconf” database, usually) to store the settings in a tree structure. But a “relocatable schema” doesn’t have a given path, the path is set when running by the application. So an external tool like
dconf-editorcannot know where to map this schema, and can only see the settings that have been changed, from the backend, not the unedited ones defined by the schema. Here, adding a setting manually would help, but that would be just going around the real problem. The (future) release 3.28 can now handle relocatable schemas, making this problem disappear.
Another growing problem is the use of Flatpak or similar technologies. Here, applications like
dconf-editorcannot access the schemas at all, just the edited keys. And, it’s possible that a future backend replacing the “dconf” one will even make accessing keys impossible in usual ways. That’s a future problem, and adding a setting manually would (only) help for some times, but it’s of course not the wanted fix.
So, if you exclude corner-cases, adding a setting manually is meaningless. If you want to test, you can of course use the
dconfcommand-line tool to add something in the “dconf” database. If what you’re looking for is how to use settings from an application, see the Glib.Settings documentation. Hope that helped. :)