Closed fiftydinar closed 7 months ago
There is a solution:
Another way of applying system-wide changes in build-time other than using dconf is to use:
What is the advantage of gschema override?
What it lacks compared to dconf?
relocatable schemas support (used for making & populating folders f.e.)
in dconf, relocatable schema appears like a classic schema:
/org/gnome/desktop/app-folders/folders/Utilities
in gsettings, it appears like this:
org.gnome.desktop.app-folders.folder:/org/gnome/desktop/app-folders/folders/Utilities/
Rare amount of options are like this, so most maintainers will avoid it successfully.
Gschema overrides have very similar format to dconfs with some little differences.
Gschema uses gsettings backend which uses .
format instead of dconf's /
for schema locations.
While dconf relies on dconf-updater service, gschema override relies on simple command for recompiling gschemas, which is done in build-time as a script after gschema override is placed (this is where useful logs are printed):
glib-compile-schemas /usr/share/glib-2.0/schemas
Gschema override is placed in this location:
/usr/share/glib-2.0/schemas
It can be named like this:
01-mysettings.gschema.override
It can be also named without a number:
mysettings.gschema.override
It is important to pick the name of gschema override, which will assure that it won't get bypassed by other overrides. Alphabetical naming has advantage compared to numerical you seen in example above:
So, if you name your gschema override like this, you will be assured it will always work:
z1-mysettings.gschema.override
zz-
prefix will take the most advantage, but it's preferable to use z1-
prefix, to make some space for downstream maintainers to use their own modifications.
Universal Blue images will use z0-
prefix in the future, so that's the reason why z1-
is preferred for downstream images.
Use gschema overrides as much as possible, use dconf-updater only for setting locks & unsupported gschema override settings.
Here's an example of how gschema.override modifications look:
For GDM modifications, you can notice that
[org.gnome.desktop.peripherals.touchpad:GNOME-Greeter]
tap-to-click=true
is used as an example.
Dconf changes which are not compatible with gschema.override:
While its functionality is great, it's the matter of time when some dconf value stops working. System & apps can get update any time, which would prevent custom configuration working.
I propose some solution to have error logging for non-working dconfs & when dconf-updater is prevented in writing the modified values. Possibly, by reading starting values with "dconf read" & comparing that to the end output. If some part of the output is unchanged from the starting values, fail then inform the user through error log.
This way, we will know which dconf values should be corrected in the future.