Ship as Federated Calendar, with the application ID
computer.federated.FederatedCalendar and the executable
federated-calendar, so it can be installed and run alongside GNOME
Calendar.
The settings schema follows the application ID too, so the two don't
share settings or install the same schema. The project name sets the
executable, gettext domain and data directory; the desktop file, D-Bus
service, search provider, metainfo and icons follow the application ID.
Internal resource paths and the template file names are unchanged, to
keep merging from GNOME Calendar simple.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
We discussed this on Matrix multiple times and came to the conclusion
that crashing the application is preferred on Nightly and during
development. We often miss a critical log message during development
because it gets swamped by all the other logs. Now we can no longer
ignore them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/857>
`WITH_CXX_BINDINGS` is deprecated in libical 4, so it's replaced with
`LIBICAL_CXX_BINDINGS`.
`LIBICAL_JAVA_BINDINGS=False` is required for libical 4.
Since we use `ENABLE_OAUTH2_WEBKITGTK4=OFF` in evolution-data-server,
we could also use `ENABLE_OAUTH2_WEBKITGTK=OFF` alongside.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/811>
davidandClaude Opus 5.5