Install gsettings schemas

[hedning]

Motivation for this change

Provide global access to gsettings schemas of installed packages.

resolves #19590
resolves #54082

Will also help with various plugins that's picked up from the global environment, but which doesn't expose its own gsettings schemas properly (eg. #42176)

Things done

Running with this on my machine right now.

[jtojnar]

The patch looks fine to me. However, I am still not convinced that this is the way to go. In my opinion, purity is one of the main benefits of Nix and I would like to push it beyond practicality – for example I was recently contemplating a setup hook that would patch C source code replacing g_settings_new with g_settings_schema_source_new_from_directory+g_settings_schema_source_new_from_directory+g_settings_new_full.

[jtojnar]

IIRC, mutter was required by g-c-c for keyboard panel, not schemas.

[hedning]

It fetches (and sets) the keybindings from mutters schema. I can make the comment explicit that it's the keyboard panel functionality that require them.

[jtojnar]

Oh, right. The keybindings XML files point to schemas. I think I have somewhere g-c-c patch that adds schemafile argument to KeyListEntries element from the time I wanted to get rid of sessionPath.

[Mic92]

I share the opinion of @jtojnar, while it is annoying at first to add these wrappers to nixpkgs say are more robust in the end then the situation we have with qt, where one can no longer run applications from nix-shell due missing paths in the profile.

[hedning]

I should've made the motivation clearer.

Run time dependencies should still be handled by wrappers, patching the source, or by automatically hardcoding paths like @jtojnar alluded to (if we could fix this in glib that would be really great).

This PR isn't meant to address those issues.

This is meant to address optional run time dependencies on schemas. Perhaps best exemplified by dconf-editor which doesn't require any single schema in particular, but gives the user easy access to modify those it can find. Currently, using dconf-editor is a pretty bad experience (it will show random stuff that have snuck in through wrappers, eg. vte terminals). Another example is gnome-control-center which builds it's keyboard panel using various schemas (from things like mutter, but also gpaste).

So while we all agree it's pretty poor design to pick up build times dependencies from the global environment. It's actually sometimes used correctly to pick up optional run time dependencies. Solving this at build time isn't really approriate as it will bloat closures and will never be complete.

[jtojnar]

Well, schemas are almost never optional dependency. We can almost always either wrap the program, or replace g_settings_new with the trio mentioned above. I can only recall two instances of data files being dependent on GSettings schemas:

• the GNOME Control Center keybindings XML brought up it this PR
• AutostartCondition= desktop files (e.g. ${orca}/etc/xdg/autostart/orca-autostart.desktop), interpreted by gnome-session

I already have somewhat messy patch for the first one and the second one should not be that big of a problem either.

dconf-editor and gsettings utility are exceptions, where all schemas are optional. But for these, this patch would not help for schemas installed by libraries, unless explicitly added to systemPackages. Actually, the only advantage this has on sessionPath is that it does not require another option in configuration.nix. I think the correct approach here is some kind of introspection of profiles’ transitive dependencies in a wrapper; conflict resolution would be the hardest part.

[jtojnar]

Actually, I already wrote the introspection code #33277 (comment), we only need to replace --references with --requisites and we can just wrap dconf-editor with it. GLib will resolve the conflicts automatically, since it basically traverses a linked list until it finds the required schema. Only disadvantage is the performance.

[hedning]

Actually, I already wrote the introspection code #33277 (comment), we only need to replace --references with --requisites and we can just wrap dconf-editor with it. GLib will resolve the conflicts automatically, since it basically traverses a linked list until it finds the required schema. Only disadvantage is the performance.

Nice, that would be a better solution (at least if the performance is okay) 👍. As you said, it's not a very common pattern (though not having access to through dconf-editor is a bit jarring, especially for new users I'd imagine).

I'll close this in favor of your suggested solution.

[jtojnar]

For the record, gst-inspect-1.0 has similar issue and we also solved it by $NIX_PROFILE-aware wrapper: #10559 (comment)

[nixos-discourse]

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:

https://discourse.nixos.org/t/gnome-control-center-wont-start-gpaste-settings-schema-not-installed/7479/3