GObject automatically notifies when passing
properties as part of g_object_new(). This
happens after the instance is created, thus
after constructed().
By passing G_PARAM_EXPLICIT_NOTIFY, we avoid
this behavior. However, we are still notifying
PROP_CONTEXT in GcalWindow. Removing this other
notify fixes the crashes related to GcalContext.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/417
Currently the label text is only updated when set_value is called and
the new value is different to the current value. So if a format callback
is configured after the GcalMultiChoice is created, this won't be
applied until the value is changed to something other than the default.
The problem in issue #100 is that the default value for "month" is
0=>January. gcal_date_chooser_init sets the format callback and then
calls gcal_multi_choice_set_value with value==0 which won't update the
label.
Fix by having gcal_multi_choice_set_format_callback update the label
text with the result of applying the format callback to the current
value.
Fixes#100
The method ask_recurrence_modification_type() currently
receives an ESource, and tried to fetch the ECalClient
from the ESource by using g_object_get_data().
However, since we moved to GcalCalendar, we do not set
this data field in ESource.
Receive a GcalCalendar instead, and use the appropriate
function gcal_calendar_get_client() instead.
Most of these are probably paranoid, not bugs. I haven't done an
exhaustive review to see what really needs it: that would be
time-consuming and require significant familiarity with the Calendar
codebase. This was just a quick check. Anyway, I vote for paranoid
when it comes to using g_signal_connect() regardless. It's dangerous,
and there's no reason to ever leave a signal connected after the user
data object has been destroyed.
Fixes#423
The new discoverer is a vast improvement over the code
that use used to have here. Right now, we fail to use
Soup to detect the URL, and that's been reported multiple
times already.
Use the new web discoverer code, and adjust the UI to
match the new code. Namely, use a GtkPopover to show
the credentials widget.
Fixes#380
This will be used by the pages of the calendar management dialog
to let it know they are actual pages, to offer an activation
mechanism, and to communicate with the dialog when they want to
switch to another page.
Soon we will start populating this subfolder with many other
calendar management files, and to avoid making the gui/ folder
a mess, move source dialog to it.
Showing these online accounts in the dialog only added
an additional step. We'll be adding a link to online
accounts in the next commit, so for now, remove the
widgets from the source dialog.
When the all-day checkbox is ticked, transforming to the
UTC timezone may change the dates of the event. On positive
timezone offsets, this happens frequently.
Fix that by only transforming to a timezone when the event
is not marked as all-day.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/issues/338
The view knows its time range, and knows what the
next or previous dates should be. So instead of
calculating the next date manually, ask the views
for that.
