9 Commits
Author SHA1 Message Date
Niklas Wimmer 1d8995c30b ci: Enabling gobject-linter
The gnomeos-basic-ci component already has support for gobject-linter
and we only need to add a config file to make it run and show up as
part of a merge request's code quality check.

I set the property enum convention to "legacy", as that is the style
we currently use. Since this is only a matter of style, I do not see
the point in changing all (>40 occurrences) of that just because.

Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/799>
2026-08-28 21:43:10 +00:00
Niklas Wimmer a17e6324e1 Post-release version bump
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/803>
2026-07-31 05:46:51 -04:00
Niklas Wimmer a79065f58b Release 51.beta
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/803>
2026-07-31 05:46:48 -04:00
Niklas Wimmer ec92fab118 tests/event: Validate schedule comparison
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/792>
2026-07-22 10:27:58 -04:00
Niklas Wimmer 81954048f9 core/event: Fix schedule comparison function
Fixes a few problems in the schedule comparison code:

- Same recurrence pointer short-circuits to TRUE: a pointer to the
  same recurrence is not a sufficient condition, because the dates
  could still be different (this is especially true if the recurrence
  is NULL for both events, but also holds if that is not the case).
  Also deleted the explicit check if only one of the recurrence
  pointers is NULL, because that is the first thing that is checked
  in `gcal_recurrence_is_equal()` anyway.
- Date comparisons only check if the date moved into a specific
  direction: the correct logic is to check if they are not the same,
  no matter in which direction the date moved.
- The time is not compared: for non all-day events, it is necessary
  to compare the time values too. The glib function that is now used
  for that also checks the date, so these checks can be collapsed
  into one.

For the second and third point it seems like some things got a bit
mixed up in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/2ee6dfc5e7bd5823bee5029a7ac3a32d3c247ba9:

- The `gcal_schedule_section_changed()` implementation already used the
  `g_date_time_equal()` function (which is now used again).
- It was `gcal_schedule_section_day_changed()` which only compared the
  dates using `gcal_date_time_compare_date()`, but this function was
  only used for edits to recurring events to determine whether to
  allow changing all instances. This commit now exposes a regression
  in this part of the code, which is tracked separately in
  https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613.

Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1612>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/792>
2026-07-22 10:27:57 -04:00
Niklas Wimmer a1b55b5ca9 tests/range-tree: Validate insertions and removals
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/798>
2026-07-22 14:13:36 +00:00
Niklas Wimmer b83a89a2e7 tests/range: Validate the compare function
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/798>
2026-07-22 14:13:36 +00:00
Niklas Wimmer ea2c637b35 core/range: Fix compare function
Fixes a regression from
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/62345668748b571939c1c7b441e44664a05a0287

Essentially, `gcal_range_compare()` is just a faster subset of
`gcal_range_calculate_overlap()`. The commit that introduced this
regression accidentally flipped the sign of the compare function,
which made it no longer match with the implementation of overlap.

The function's implementation also did not match its doc comment,
returning any integer instead of only `-1`, `0` or `1`. Since the
behavior described in the doc comment is more commonly used for
comparison functions, the implementation was adjusted to match it.

To avoid any such failures in the future, the next commits will
add tests to validate.

Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1615>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/770>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/798>
2026-07-22 14:13:36 +00:00
Niklas Wimmer 6ea211fbf9 flatpak: Remove intltool module
GNOME Calendar itself stopped depending on intltool in 3.25.3. After
intltool got removed from org.gnome.Sdk, it was added to our manifest
in 2019, because EDS still depended on it.

EDS stopped depending on intltool in 2021 (see linked MR).

Since this was the only module we used from the `shared-modules`
project, I also removed that git submodule.

See: <https://gitlab.gnome.org/GNOME/evolution-data-server/-/merge_requests/78>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/802>
2026-07-22 13:24:28 +00:00