Design and implement a new set of calendars/accounts management dialogs to add / edit / subscribe to calendars
With the various improvements merged to main
(for the 45.x series) regarding the dialogs in the "Manage calendars" dialog, and the issues we've encountered like #566 (and its many, many related issues), we are reaching a point where, to quote Georges, "a mild design review of the calendar management dialog is beneficial. Managing calendars has always been the pain point in gnome-calendar."
This ticket serves as a meta issue to assemble all the problems that we'd like to solve. Input from the GNOME design team would be welcome.
Overview of the current state of the GUIs
The main "Manage calendars" dialog has been pretty much unchanged since forever, though I'd like to add a visual indication of read-only calendars #961 (closed), for which there is currently an attempt at conveying that with icons in !304 (closed).
Below are screenshots (and observations) about the sub-dialogs of the "Manage calendars" dialog.
Editing an existing calendar
It currently looks like this (EDS-configured Google calendar on the left, NextCloud GOA calendar on the right, where the cogwheel button opens the GNOME Control Center's online accounts settings).
Is this good and sufficient? Should the "Display calendar" GtkSwitch widget still be there, while it also appears in the parent list of calendars, and in the calendars popover widget?
Consider the various types of calendars (local, caldav/webdav, Google, GOA, etc.)
Adding new calendars
That GUI page currently looks like this:
What's wrong with it, you ask? From one of @feaneron's comments in !129 (closed):
This entire page of the dialog needs to be redesigned. There's no way to we can fix this issue without separating local and remote calendars. Fetching calendars from an URL is much more complicated than creating a local calendar, because one URL can provide multiple calendars, and right now we don't even display which calendars are found. I'm going to close this merge request, even though it would almost be an acceptable workaround, because I want this to be fixed properly on the design side first. Sorry.
The further clarification I have obtained is that we need a "full redesign of the page to add new calendars" shown above, because:
The flow for adding a single, local calendar is completely different and separate from the flow for importing remote calendars. Related to that, merging both flows in the same page is prone to confusion, so I think the appropriate fix is to provide separate sub-pages for local and remote calendars; fundamentally, we should make it impossible to fill both pages simultaneously, which is what i think adds the most to the confusion
It's a well-scoped and concrete redesign task that should take one single release to be implemented, and won't need to be broken in smaller steps. It's a small-sized task and medium priority.
Components that need design for adding calendars
First, we need someone to spend time designing dedicated UIs that can replace the above, for handling these three scenarios (for starters):
- Creating a new local calendar (that's the super easy one!)
- Importing a local .ics calendar or event file (see also #255 vs #390 + #1131)
- Adding (connecting to) a remote web calendar (via HTTPS, webcal://, or some other typical URI scheme, with and without password prompts and with/without calendar selection)
Also (bonus points): a GUI for handling backend errors (#17) and backend problems in general (such as expired credentials, #265).
Out-of-scope/deferred stuff
Not needed / not easily feasible for now:
-
Adding (connecting to) a remote GOA/EDS calendar: nothing to be done here, Evolution Data Server handles it all for us, no need to do anything about it -
Creating or deleting remote calendars server-side (via EDS or via GOA+EDS, whether it's Google Calendar, NextCloud, iCloud (see #303), a GOA-controlled CalDAV, or something else supported by EDS, with authentication if needed, etc.): this feature does not exist in GNOME Calendar, and it does not exist in Evolution / EDS either.
- In theory maybe we could workaround that by using the caldav address that GOA gives us (because GOA only provides us/EDS with the credentials), but that's an entirely separate project and not really related to redesigning the page.
- EDS provides no utilities to create remote calendars, that burden falls on apps themselves (e.g. Evolution, GNOME Calendar) to do it.
- We'd need to implement 2 things: (1) ability in the client app (GNOME Calendar) to create/delete calendars on any caldav server, then (2) use the caldav address and credentials that GOA accounts provide us to do that. We have neither of that right now, and it won't be trivial to add remote calendar creation on caldav
Prior art
For what it's worth, these are the types of dialogs Evolution presents (in its own GUI, not in GNOME Calendar) when creating a remote calendar: