GNOME Bugzilla – Bug 766318
Use the org.gnome.desktop.calendar schema instead of our own
Last modified: 2016-05-26 21:07:07 UTC
See the blocking bug - Shell and Calendar want to share this setting. I didn't handle migration, instead just dropping the old schema - it wasn't clear how to do this. If you want me to, please advise.
Created attachment 327693 [details] [review] Use the org.gnome.desktop.calendar schema instead of our own This setting is now shared by Shell and Calendar.
(In reply to Iain Lane from comment #0) > I didn't handle migration, instead just dropping the old schema - it wasn't > clear how to do this. The easiest option would be to keep using the "/org/gnome/shell/calendar/" path in the new schema, if Bastien doesn't mind breaking the convention that schema name and path match. Otherwise I don't think migrating the setting is worth the code, and users would need to set it again.
Created attachment 327695 [details] [review] Use the org.gnome.desktop.calendar schema instead of our own This setting is now shared by Shell and Calendar. (bumped the g-d-s requirement)
Review of attachment 327695 [details] [review]: ::: configure.ac @@ +120,3 @@ PKG_CHECK_MODULES(TRAY, mutter-clutter-1.0 gtk+-3.0) PKG_CHECK_MODULES(GVC, libpulse >= $PULSE_MIN_VERS libpulse-mainloop-glib gobject-2.0) +PKG_CHECK_MODULES(DESKTOP_SCHEMAS, gsettings-desktop-schemas >= 3.21.2) That version doesn't exist (nor does your g-d-s patch bump it), so this will break the build
(In reply to Florian Müllner from comment #4) > Review of attachment 327695 [details] [review] [review]: > > ::: configure.ac > @@ +120,3 @@ > PKG_CHECK_MODULES(TRAY, mutter-clutter-1.0 gtk+-3.0) > PKG_CHECK_MODULES(GVC, libpulse >= $PULSE_MIN_VERS libpulse-mainloop-glib > gobject-2.0) > +PKG_CHECK_MODULES(DESKTOP_SCHEMAS, gsettings-desktop-schemas >= 3.21.2) > > That version doesn't exist (nor does your g-d-s patch bump it), so this will > break the build I checked previous commits and they bumped it when making the release so I'm not exactly sure what it's normal to do there. See for example: https://git.gnome.org/browse/gsettings-desktop-schemas/commit/?id=a0dcef6ca37258a14615a84e6cfa5733cd711e88 https://git.gnome.org/browse/gsettings-desktop-schemas/commit/?id=e8a416f370626cf825cd1043fce1561fe675b3d7
(In reply to Iain Lane from comment #5) > I checked previous commits and they bumped it when making the release If your intent is to not commit the patch until there is a g-d-s release, then that's fine. Breaking the build until there is a release is not.
Either that, or bump the release when committing the g-d-s patch. I'll let the g-d-s maintainers decide on that one. It'd be good to get all of this into 3.21.1 though.
Doing a version bump that is not pre- or post-release (depending on the module's policy) would be weird. If we don't get an early g-d-s release, you can push the patch without the version bump, and I'll do it when we release 3.21.2.
Attachment 327695 [details] pushed as 38406e0 - Use the org.gnome.desktop.calendar schema instead of our own We now have a gsettings-desktop-schema release with the new schema, so let's push this.