gnome-calendar merge requestshttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests2024-02-18T20:39:21Zhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/413gui/event-widget: Set weak ref on preview popover2024-02-18T20:39:21ZGeorges Basile Stavracas Netogui/event-widget: Set weak ref on preview popoverSo that when it's destroyed, the internal ref becomes NULL and we then
can safely call g_clear_pointer() on it.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1154So that when it's destroyed, the internal ref becomes NULL and we then
can safely call g_clear_pointer() on it.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1154GNOME 46https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/356core/calendar-monitor: Join view thread in dispose2023-08-25T20:43:01ZGeorges Basile Stavracas Netocore/calendar-monitor: Join view thread in disposeJoining the calendar view thread in finalize is too late; dispose
is an earlier phase, and recoverable.
Do that.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1085Joining the calendar view thread in finalize is too late; dispose
is an earlier phase, and recoverable.
Do that.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1085GNOME 45https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/312gcal-event-popover: Fix for wrapping title text in event popover summary2024-02-24T05:44:39ZShubham Singhgcal-event-popover: Fix for wrapping title text in event popover summaryPreviously, the event title header text in the details popover was being ellipsized(truncated) instead of wrapping, making it difficult to read longer titles.
This commit updates the gcal-event-popover.ui file to set the "wrap" and "wrap...Previously, the event title header text in the details popover was being ellipsized(truncated) instead of wrapping, making it difficult to read longer titles.
This commit updates the gcal-event-popover.ui file to set the "wrap" and "wrap-mode" properties to "true" and "word-char", respectively, for the summary label object.
This ensures that the event title header text is wrapped and more readable in the summary popover.
Fixes #1016.GNOME 45https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/306Increase search range, remove artificial limits2023-08-03T02:09:07ZGeorges Basile Stavracas NetoIncrease search range, remove artificial limitsSee commits. This is about as far as I am comfortable going for GNOME 44. More sophisticated search behaviours won't land until we branch GNOME 45.See commits. This is about as far as I am comfortable going for GNOME 44. More sophisticated search behaviours won't land until we branch GNOME 45.GNOME 45https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/270gcal-recurrence: Handle invalid 'until' time2022-11-17T11:07:09ZMilan Crhagcal-recurrence: Handle invalid 'until' timeWhen the until's time part is invalid, the libical claims the time
as valid, but the conversion into the GDateTime fails and returns NULL.
Such events, which claim to have until-date recurrence, but NULL 'until'
cannot be edited, because...When the until's time part is invalid, the libical claims the time
as valid, but the conversion into the GDateTime fails and returns NULL.
Such events, which claim to have until-date recurrence, but NULL 'until'
cannot be edited, because they cause a crash of the application.
More information can be found downstream at:
https://bugzilla.redhat.com/show_bug.cgi?id=2135772
Related to https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/892GNOME 44https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/202event-popover: Fix popover for all-day multi-day events2024-02-24T05:44:39ZBjörn Daaseevent-popover: Fix popover for all-day multi-day eventsAll-day multi-day events go, e.g. from 01/01/2022 00:00 to 01/03/2022 00:00.
The old logic would have shown January 1 - January 3. This, however, is
incorrect and should instead be January 1 - January 2. As a result,
subtract one day fro...All-day multi-day events go, e.g. from 01/01/2022 00:00 to 01/03/2022 00:00.
The old logic would have shown January 1 - January 3. This, however, is
incorrect and should instead be January 1 - January 2. As a result,
subtract one day from the end date when in the all-day multi-day case.GNOME 42https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/166time-zone-monitor: Use local timezone as fallback without dbus service2021-04-11T00:34:31ZSebastian Kellertime-zone-monitor: Use local timezone as fallback without dbus serviceThis is a fix for https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/703 and a small leak fix I noticed while looking at the code.This is a fix for https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/703 and a small leak fix I noticed while looking at the code.GNOME 40https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/150gcal-timeline: never reset completed_calendars2023-08-23T01:23:11ZMichael Catanzarogcal-timeline: never reset completed_calendars Since 78cb11c64d199b77761ba55bdd3d3e6b0dcb06af, GcalCalendarMonitor now
notifies when a completed calendar transitions to incomplete, and
GcalTimeline decrements its completed_calendars counter. But we forgot
to remove th... Since 78cb11c64d199b77761ba55bdd3d3e6b0dcb06af, GcalCalendarMonitor now
notifies when a completed calendar transitions to incomplete, and
GcalTimeline decrements its completed_calendars counter. But we forgot
to remove the code that resets completed_calendars when previously
needed. That's not required anymore, because we can trust
GcalCalendarMonitor to do the right thing.
In my case, I have 5 calendars enabled and 6 total. When starting
gnome-calendar, all 5 are successively completed, and
completed_calendars increments from 0 -> 1 -> 2 -> 3 -> 4 -> 5. Then,
when transitioning month view from January 2020 to December 2019, we
call reset_completed_calendars() and completed_calenders gets clobbered
to 0. Then it decrements from 0 -> -1 -> -2 -> -3 -> -4 -> -5 as the
GcalCalendarMonitors notify that they are no longer completed. Well,
that is what would happen, if it didn't crash when decrementing to -1.
We assert -1 <= 6 (the total number of calendars) and crash because -1
gets promoted to a huge unsigned int, since we're comparing signed to
unsigned. (That crash would have been avoided if we used
-Wsign-compare, although that warning would not have caught the logic
problem.)
Anyway, since GcalMonitor now notifies when calendars are no longer
complete, it is safe to simply remove reset_completed_calendars().
GcalTimeline will still notify if it needs to change its own complete
property (in on_calendar_monitor_completed_cb).
Fixes #647GNOME 3.38Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/105quick-add-popover: Use more g_signal_connect_object2019-10-07T15:49:28ZMichael Catanzaroquick-add-popover: Use more g_signal_connect_objectWe need to disconnect from the GcalManager when the GcalQuickAddPopover
is destroyed, or crashes happen.We need to disconnect from the GcalManager when the GcalQuickAddPopover
is destroyed, or crashes happen.GNOME 3.34Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/104quick-add-popover: Use more g_signal_connect_object2019-10-07T15:48:36ZMichael Catanzaroquick-add-popover: Use more g_signal_connect_objectWe need to disconnect from the GcalManager when the GcalQuickAddPopover
is destroyed, or crashes happen.We need to disconnect from the GcalManager when the GcalQuickAddPopover
is destroyed, or crashes happen.GNOME 3.36Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/98Fix double free in gcal_quick_add_popover_set_property2024-02-24T05:44:39ZMichael CatanzaroFix double free in gcal_quick_add_popover_set_propertyThis already uses an autoptr.
Fixes #455This already uses an autoptr.
Fixes #455GNOME 3.34Georges Basile Stavracas NetoGeorges Basile Stavracas Netohttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/74Fix a crash in update_default_calendar_row()2024-02-24T05:44:39ZMichael CatanzaroFix a crash in update_default_calendar_row()This function is crashing in 3.32 because the manager object is invalid.
I think there are two related bugs:
First, it looks like gcal_quick_add_popover_set_property() is failing to
disconnect its signals from the old GcalManager before...This function is crashing in 3.32 because the manager object is invalid.
I think there are two related bugs:
First, it looks like gcal_quick_add_popover_set_property() is failing to
disconnect its signals from the old GcalManager before setting the new
one. In one backtrace, I see the GcalManager emitting the signal is
different than the GcalQuickAddPopover's current manager, which is
surely unintended.
But that shouldn't be enough to crash on its own, since the
GcalQuickAddPopover should still have a valid manager, even if not the
intended one. So I suspect the GcalQuickAddPopover itself is invalid at
this point. (The crash occured for me after adding an event, so it was
probably just destroyed.) GcalQuickAddPopover is not disconnecting these
signals in dispose, which is unsafe. We can avoid the need to do so by
using g_signal_connect_object().
Hopefully fixes #416 for the 3.32 branch.
https://bugzilla.redhat.com/show_bug.cgi?id=1509551https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/144Don't crash when trying to add calendar from invalid URI2024-02-24T06:38:51ZNiklas CathorDon't crash when trying to add calendar from invalid URIThis change fixes a crash that occurs when entering an invalid URI in the "Import a Calendar" section within the "New Calender" dialog.
**Steps to reproduce:**
1. Visit the "New Calendar" dialog, via "Manage Calendars..." -> "Add Calend...This change fixes a crash that occurs when entering an invalid URI in the "Import a Calendar" section within the "New Calender" dialog.
**Steps to reproduce:**
1. Visit the "New Calendar" dialog, via "Manage Calendars..." -> "Add Calendar..."
2. Enter a URI that has an unsupported scheme, and an empty host, for example "caldav:/"
3. The app crashes
**Expected behavior:** The app indicates that the URI is invalid.Niklas CathorNiklas Cathorhttps://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/26Fix GCalManager test2018-03-04T09:23:56ZIñigo Martínezinigomartinez@gmail.comFix GCalManager testThese patches sets the proper environment to rn GCalManager test. The first one takes advantage of the configurable tags which can be used along meson's `configure_file` and creates the schema in the build directory.
The second one, com...These patches sets the proper environment to rn GCalManager test. The first one takes advantage of the configurable tags which can be used along meson's `configure_file` and creates the schema in the build directory.
The second one, compiles the schema to be ready for the GCalManager test and sets the environment variables necessary for the test to find them.
However, although this all must be done, the test still doesn't work due to an error:
```
--- command ---
G_TEST_SRCDIR='/gnome-calendar/tests' G_TEST_BUILDDIR='/gnome-calendar/_build/tests' GSETTINGS_SCHEMA_DIR='/gnome-calendar/_build/data' GSETTINGS_BACKEND='memory' MALLOC_CHECK_='2' /gnome-calendar/_build/tests/test-manager
--- stdout ---
/manager/new:
--- stderr ---
(/gnome-calendar/_build/tests/test-manager:30472): GLib-CRITICAL **: 10:09:35.324: g_hash_table_destroy: assertion 'hash_table != NULL' failed
-------
```
The original duplicated issue is at #189.Georges Basile Stavracas NetoGeorges Basile Stavracas Neto