When tabbing into a grid or list of items that are selectable,
we want to focus the selected item when entering it. At the moment,
we only focus the first or last item in the date chooser grid,
rather than the selected item.
Co-authored-by: Niklas Wimmer <niklas@viric.eu>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/869>
This menu item was found to be confusing in a small experiment with 3
people. Since online calendars are already accessible when adding
calendars in the calendar management dialog, this menu item can be
removed.
Closes#1642
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/876>
Instead of checking `g_date_time_get_week_of_year()`, which doesn't
care about "first day of week" settings, we use our
`gcal_date_time_get_start_of_week()` utility function. This function
determines the first day of the week the passed date belongs to,
constructs a new `GDateTime` object that represents the first day
of week as 'Y-M-D 00:00:00' in local timezone, all while taking
into account the "first day of week" Desktop setting.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1212>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/868>
Since we now have fatal criticals enabled, we are prone to crashes
caused by our external dependencies emitting criticals. The newest case
is the Adwaita About dialog. The critical happened because `ministream`
couldn't find a release tag for 52.0
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/864>
`add_event_to_block()` assumes that the child widget has never been
parented, so it will always set the parent widget when the widget
is already parented, which triggers a critical error in GTK.
This patch addresses this situation by only parenting when the
widget has just been created. Additionally, it asserts that the
parent widget is `self` in the end, so that it crashes if this
is incorrect.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1643>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/863>
The `gcal_agenda_view_first_weekday_changed` uses the same
`gtk_list_view_scroll_to` method that expects the scroll position to be
smaller than the number of items in the list model.
When the list model contains no items, the method reports a critical
which crashes the Calendar whith `fatal-criticals` enabled.
This is the same fix that Georges made in the
`gcal_agenda_view_set_date` method. We now check the number of items
before trying to scroll the list view to position zero.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/861>
It's possible to change the density of the week view, but only through
pinch-zooming or Ctrl+scroll wheel. This means it can't be done with
only the keyboard, and since neither of these methods are documented,
it's not discoverable either.
This adds shortcuts for zooming the view in and out, and documents them
in the shortcuts dialog to make them discoverable.
Helps #1556
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/859>
`gtk_list_view_scroll_to()` is documented to require that `pos` is
smaller than the number of items in the model. We were not checking
if the model was empty before calling this function, which could
lead to criticals.
Check if the listview model has any items before scrolling it.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/860>
At the moment `gcal_date_chooser_set_date()` is automatically setting
the day to 1, which is undesirable behavior for a method that is
designed to "just" set the date. By connecting to
`GcalMultiChoice::explicitly-changed`, we can simply have the day
set to 1 to accompanying callbacks.
Currently, `multi_choice_changed()` is invoked 50 times at startup.
By using `GcalMultiChoice::explicitly-changed`, `multi_choice_changed()`
is only invoked 10 times. This is still more than ideal, but it's
a significant drop.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1639
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
We currently rely on connecting the `notify::value` signal,
which is emitted every time the value is changed explicitly or
implicitly. This can be problematic when, for example, the user
scrolls in the month view, which changes the value of each
GcalDateChooser widget, and each minor difference will re-emit
the signal until it's over. The `GcalMultiChoice::user-changed`
signal will only emit when the user presses the
previous/next buttons.
The next commit will port GcalDateChooser
to `GcalMultiChoice::user-changed`.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/837>
Change the 'get_first_weekday' function to number the weekdays
Monday(1)-Sunday(7) like ISO does. Change the function name to reflect
that. Add tests for different locales, although the tests depend on
system-installed locales.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/822>
Start the enum from Monday-Sunday (1-7). Adapt code that references the
`is_workday()` utility method, which in turn uses the GcalWeekDay enum
to combine pairs of days by bitwise or-ing.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/822>
Since we refactored all events widgets and date headers to be
constructed by GtkListView directly, we are able to use
`gtk_list_view_scroll_to` to jump to the top of the list when opening
the agenda view, and changing date, instead of needing a complicated
timer and GSource callback
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/809>
Similar to the previous commit, we now create the date header label
using the model provided directly from `ListView:header-factory`, by
querying the date of the day the item is in the section of.
This requires copying the auxiliary method `new_date_header_string ()`
from `gcal-agenda-view-day-item.c` to `gcal-agenda-view.c` for
generating the appropriate using facing string for the header
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/809>