This commit updates the dependencies for libhandy to the tagged 1.0
release and changes the code to accomodate the changes from
libhandy-0 to libhandy-1.
Notable changes:
edit-dialog: HdyDialog has been dropped in [1]
alarm-row: action child type in HdyActionRow has been removed.
[1] https://gitlab.gnome.org/GNOME/libhandy/-/merge_requests/434
GcalEditDialog code pre-dates GcalEvent and apply changes directly
to the underlying ECalComponent. However, it doesn't commit the
sequence after doing so, which opens the door for doom.
Commit the component sequence after changing the recurrence data.
When moving an event to another calendar, the GcalEvent instance
that is being held by GcalEditDialog is not valid one. On the other
hand, moving an event shouldn't trigger an update either.
For now, simply fake a GTK_RESPONSE_CANCEL. In the future, it'll
be better to move most of the GcalWindow code to GcalEventDialog
itself.
Edit a cloned event instead of the actual event, so that it
can preserve the original event's integrity. This allows for
a major edit dialog cleanup in the future.
Right now, comparing dates with gcal_date_time_compare_date() gives
the exact opposite result of when comparing using g_date_time_compare().
As shown by this patch, this was a source of *many* bugs.
Turns out, all we have to do is rewrite the URL to https://. I'm
surprised this works, but I don't see any problems with it. I tested
subscribing to webcal://www.gnome.org/start/unstable/schedule.ics.
See also: #481
Currently, when the user enters an invalid URL -- a URL that does not
pass SoupURI's URI format validation -- then we set the error style
class on the URL entry to turn the border of the entry red. For example,
if I try to enter "dog" then GNOME Calendar catches this and flags the
entry as red.
But there are some problems.
First of all, GNOME Calendar doesn't do anything to prevent users from
entering URLs that are syntatically valid but not usable as calendars.
The code knows whether the URL was successfully parsed as a calendar
file, it just doesn't do anything with this information. So there is no
red warning if I try to use https://example.com as a calendar, even
though the dialog knows that it didn't work.
Secondly, GNOME Calendar allows pressing the Add button even if the URL
entry contains invalid input, but only if the Calendar Name has been
entered. The dialog thinks: "if I have a name, but not a valid URL, then
the user wants to create a new, empty local calendar!" But this is not
right. If the user has typed anything in the URL entry, then the goal is
to import a new calendar, not to create a new one.
This commit changes set_url_entry_error() into update_url_entry_state(),
and gives it responsibility for updating the add button sensitivity and
URL entry pulsing in addition to the URL entry style class, solving both
of the above problems.
As a side effect, this also closes a race window where the Add button
remains sensitive for half a second after typing new text in the URL entry.
At this point, we don't yet know whether the URL is valid, because we
wait half a second before validating the URL, so we shouldn't allow the
user to activate the Add button during this race window.
Fixes#481
This check passes if the URI is empty. Normally this callback only runs
when there is text in the URL entry, but there is a race window where
the user could delete it first. (Passing NULL to a SoupURI creates an
invalid non-NULL empty URI that can be filled in later.)
When multiple calendars with the same name exist, their relative order in the
list is random and changes e.g. when toggling the checkmark next to them. The
result is glitchy behavior.
Now when two calendars have the same name we do a secondary sort by their ID,
resulting in a nice deterministic order.
With the introduction of the new event editor, Calendar
saw it receive sections of editable properties of the
events. One of these sections is the "Reminders" section,
that contains the reminders (also called alarms) of an
event.
However, this section's row to add a new alarm does not
match the proposed mockups for it. It currently has a
combo box that shows the popover with selectable reminder
times, instead of being a clickable row.
Make it a clickable listbox row, and show the alarms popover
when clicked.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/502
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
