The window would either set focus to the event widget or a
focusable ancestor, no matter how the event popover was being
closed.
This caused a major accessibility regression where,
whenever the event editor dialog opened from the event
popover, the window set focus to the event widget instead of
the content inside the dialog, which made the dialog incapable
of navigating through until the dialog was focused. This also
prevented mnemonics from being triggered.
This patch addresses that bug by only setting focus whenever
the popover is being closed explicitly; as in, when the user
presses outside the popover to hide it or pressing escape.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1398
Currently, iterators over the GcalWindowView enum relied
on knowing the first and last enum value. But we know,
without knowing which is the first, that an enum in C
will assign 0 to its first value if not otherwise
specified.
And with the trick of a new end value similar to N_PROPS,
we can determine the amount of available window views
without relying on know which it is.
Signed-off-by: Markus Göllnitz <camelcasenick@bewares.it>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/542>
Creates a chooser managing a GDateTime. The chooser allows the user
to change the date, the time and the timezone independently.
This replaces the precedent GcalTimeChooserRow widget, because it is
easier to manage the different interactions with the user in a single
widget.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
When the user deletes a calendar in the calendar management dialog, a
popover allows them to undo the deletion. The calendar is fully deleted
only when the toast is dismissed or when the toast reaches its timeout.
When the user closes the calendar management dialog without dismissing
the toast and before the end of the timeout, the calendar can still be
manipulated for a short period of time.
To fix this, I removed the calendar-management-dialog from the UI of the
window, and made the window create and destroy the dialog on demand.
This forces the toast overlay to dismiss all toasts.
A new widget to perform drag and drop operations, for example,
dropping ICS files to the GcalWindow. It allows to overlay
a child for visual feedback when a DnD operation is done.
either in the main window or in the import dialog,
depending on whether none could be imported, or just some
of them.
It is based on Loupe's DragOverlay widget.
Closes#1257
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.
Shortcut is added so that time-related system settings can be easily
accessed. See #1023
The code is largely just a copy-paste of the code that opens the
"Online Accounts…" menu.
Fixes#1023
* Use the sidebar's search entry for search shortcut when folded
* Set context on the sidebar's search entry
* Drop context GtkExpression from gcal-toolbar-end.ui
The people who introduced this code were not careful enough to
make sure the code they removed from GcalWindow was added back
in GcalToolbarEnd.
They also simply commented out some code instead of properly
reimplementing that.
I regret having trusted their code :(
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/880
Every once in a while when I'm deleting an event gnome-calendar crashes.
I dug in a bit, and it seems the reason is
adw_toast_overlay_add_toast takes ownership of the passed in reference.
This is a little idiosyncratic for something that's not GInitiallyUnowned,
but it appears to be the API nonetheless.
GCalWindow assumes it owns the reference.
This commit makes both users of the toast happy by adding a ref call.
Cannot use g_clear_pointer() here, because it unsets the pointer first and
only then calls the free function, which means the test on self->delete_event_toast
NULL-ness would be satisfied in the on_toast_dismissed_cb(), thus the previous
event delete attempt would be "cancelled" internally.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/858
Button sensitivity is automatically updated with action state.
By taking advantage of this we can use the `win.today` action
on multiple buttons without needing to update every button.
For the sake of smooth adaptivity, we need the toolbar buttons
to be constant in both modes instead of moving places from one
mode to another. Instead of duplicating these groups of
buttons, we can refactor them into an object for toolbars
and use them in multiple places.
This commit takes the widgets from the end of the header bar and
creates `GcalToolbarEnd`, which is used in the header bar and the
mobile action bar.
