When importing .ics files as events,
you can assign the resulting events to any writable calendar,
even those hidden from the view.
However, it is good to have a hint of such calendars being invisible.
That way, users can have predictable expectations.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1184
Reading the `get_source_parent_name_color` call after `color_paintable`,
one gets the impression they are somehow related, but they are not.
Furthermore, this unfortunate location complicates my upcoming changes.
Let's relocate that code next to the context where it is actually used.
This improves clarity and maintainability.
In practice, the name and color widgets are currently meant to be used
when creating a local calendar, not when subscribing online, especially
as a single online calendar link can bundle multiple calendars.
This makes the scope of those widgets clearer,
and also makes the dialog more balanced.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/566
Replace the manually positioned & styled group label by a property
This simplifies the XML code, makes the style match the rest of the UI,
and prevents libadwaita from sometimes moving such labels to the bottom.
Now that the "Open" button has been removed,
it is now a feature to "Connect" rather than "Import",
so update the section title to reflect that.
Also give a hint as to what protocols are supported.
A file imported as a "new calendar" would make it dependent on the file.
This feature was confusing everybody and is downright dangerous.
This does not prevent anyone from creating normal calendars,
and importing events from .ics files into them.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/390
This avoids some web servers or WAFs doing weird stuff with our requests
which would lead to situations where our web calendar source discovery
would face server errors, redirects, incorrect contents, etc.
Fixes#651
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/290
When subscribing to one or multiple online Webcal or CalDAV calendars,
do not unexpectedly create an extra local calendar.
While this doesn't allow customizing names & colors while subscribing,
users can still easily set those just after adding the subscriptions,
as they are then returned to the "Calendars" page of "Manage Calendars".
Punting this to a separate step might not seem like the "perfect" flow,
but it works well enough and fixes the buggy UX that we currently had.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/566
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/978
Non-technical users may not realize why they can not edit some events
from read-only subscribed remote calendars.
A symbolic padlock icon does not suffice to make this obvious.
This tooltip makes the UI self-documenting, and improves accessibility.
A more realistic default delay avoids spamming the search backends.
Benefits of this approach:
* Improves overall performance, allows wider search timeline ranges;
* Reduces power consumption;
* Reduces or eliminates flickering in the GUI;
* Reduces the amount of trace logging noise by more than 15x.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1170
In commit 1494f7407, we focus the summary entry when opening the dialog.
However, this prevents the Escape keyboard shortcut from working
when opening a read-only event after having opened a writable event.
Set focus onto the "Done" button when showing a read-only event,
as it's the only widget that can be activated/clicked in this situation.
This makes the "Escape", "Spacebar" and "Enter" keyboard shortcuts work.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1180
The "Done" button was apparently meant for read-only events,
while the "Save" action was for everything else.
It didn't work correctly because of a mismatch between code and UI XML.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1142
Rewrite the text to properly market the app,
while avoiding referencing the target environment (GNOME).
Broadly emphasize the UX, existing key features, intended use,
and benefits of the application for the user in their day-to-day lives,
without over-selling it either.
We can augment this description in the future when more core features land.
Fixes issue #1109
These are still hardcoded instead of measuring the available space,
but it's better than nothing in the meantime.
Decent WMs size the window correctly if width/height exceed the screen.
Also, allow the Notes field to expand vertically, to fill the space.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/602
