This refactor combines the functions
gcal_utils_launch_online_accounts_panel and
gcal_utils_launch_datetime_settings_panel into a single function that
takes a panel ID as an argument.
Move the add button from the headerbar into the dialog, make it
a pill button, and update the button label with the number of
calendars that will be added.
The interfacing that GcalCalendarManagementDialog had is somewhat
similar to AdwNavigationView, with pages and signaling basically
matching the same semantics.
We can save some code by switching to AdwNavigationView then, as
the heavy-lifting of page management is done there now.
The headerbar of the dialog is no more; instead, each page has its
own headerbar that automatically gets a back button.
Page activation and deactivation works essentially the same, but
uses AdwNavigationView signals to manage that.
The implementation of the credentials popover has relied on a hack,
and sadly this hack doesn't work anymore.
It's too late for a redesign, so for now, just put it into a dialog
and show it on top of the calendar management dialog.
The color chosen in the new calendar page is currently ignored
when creating a new calendar, as described in #681.
Added a callback similar to that used for the name text entry,
allowing new calendars to be created with the chosen color.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/681
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.)
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
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
