about switching from dconf to gschema overrides for gnome customization
I understand the caution. I think that issue with why your & Arcitec modification failed is because of the naming.
21 Replies
we should probably thread this
I think you used 50_ instead of 50- for naming gschema override
and that caused it to not implement the changes
When using zzz-nameofoverride-gschema.override
you will be ensured that modifications will apply
.
This thread is about migration from dconf to gschema override for at least Bluefin & Bazzite, if people are not aware of what is talked about
and referencing this PR https://github.com/ublue-os/bluefin/pull/858
Here, I wrote in detail in how to get gschema working properly. I tested this on my own image & it works:
https://github.com/ublue-os/bling/issues/53#issuecomment-1915474038
and... my PR which is old and broken... was https://github.com/bsherman/ublue-custom/pull/6
The only thing I did not document in GitHub link is using
--strict for automatic abort on error.
For now, it just reports the error, but keeps the build going.interesting that likely the only problem i had was "99_foo" instead of "99-foo"
If we agree on this change, I think we should have a time clearance on not merging any dconf stuff before this transition is completed
I could close the current PR & start again to ensure there are no conflicts, as there are some currently
don't worry about PR maintenance on this... i intend to test the concept for myself and on bluefin's behalf.
I liked the idea months ago, and still do... just need some time to check it out.
It's a shame that
--strict is failing because of 1 invalid key used by Fedora
If we could include only our gschema override into this to make it work, it would be great
However, the only location is /usr/share/glib-2.0/schemas unfortunately
So it would fail on errors for our gschema onlythis stuff is great and I think we need it, I just want to make sure we don't skew bazzite and bluefin away from each other. It's more of the timing issue since we're also close to the installer. we don't want to be in a major transition in both of those and then that day "hey the installer is ready let's go!"
like I'm hoping to quiet bluefin down for a bit once we finish the quadlets
but as a bonus, we do have a testing branch now
I solved the conflicts, figured out
I understand your point of view, but I think we can do transition without issues. I think it is a good time to transition around this period now, than after new installer is released.
As you said, you hope Bluefin quiets down around that period after
I mean, no rush of course
@Kyle Gospo @EyeCantCU Are you open for this change in Bazzite too?
yes, though with the amount of gnome extensions we tweak I worry a bit
As long as extensions use /usr/share/glib-2.0/schemas location, you will be safe
I only know Caffeine extension which doesn't do this, which should be fixed in spec file
in that case, dconf will suffice
we have
-testing branch/image after all, where we can test each dconf/gsettings key when neededawesome, yeah this looks like a great change then
all for it
to be clear, i understand this to mean, any extension NOT respecting the proper schema location simply can't be configured via the gschema override... it doesn't mean we break extensions
if that happens, dconf can suffice, as it does not care about schema locations
rephrased once more, just to be clear
I managed to add support for aborting on errors:
https://github.com/ublue-os/bluefin/pull/858/commits/4a47ba37dbe4457b5ea2c9df6aa008a471f58a89
Here's how it looks like for my image:
Success:
https://github.com/fiftydinar/gidro-os/actions/runs/7734127817/job/21087553625#step:14:1090
Fail:
https://github.com/fiftydinar/gidro-os/actions/runs/7734266214/job/21087947001#step:14:1084
I misstyped
org.gnome.desktop.wm.preferences title-bar-font on purpose, proper key should be titlebar-font. Bluefin previously used the same incorrect key like I mentioned in example, which makes it perfect for fail demonstration.
And build-time is actually not increased, as gschema is compiled instantly. That was my mistake in commit noteok, i've marked the PR ready for review and commented my thoughts.
thanks for the work on this @fiftydinar
No problem.
I would like to ask something if I may.
Can you explain me how to test the image with this PR only? If I enable GitHub Actions & build with this PR branch, will it pull the ghcr.io/fiftydinar/bluefin image with those PR changes?
fair question... but we don't push images to ghcr from our PR builds in ublue-os... so....
what i usually do is build the image locally and then manually push to a local container registry on another machine at home
I tested the image & everything works now except LogoMenu settings.
However, It's possible to fix it.
Check the updated PR which contains explanation.