Currently, clicking on a calendar in the sidebar's listbox traps
the keyboard focus. As a result, pressing PageUp or PageDown
scrolls the listbox instead of switching the date.
Similar to commit fbc18174 for the week view, this adds a
capture-phase ShortcutController to the calendar listbox. This
ensures that PgUp and PgDown consistently switch month or week
regardless of whether a calendar item is focused.
Fixes#1593
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/771>
The current notes text view has had a 2px offset for
an unknown amount of time, due to us magic-numbering
margins and/or padding. This approach works a little
bit differently, in that it uses the `.editable-area`
style class and sets the overlay's CSS name to "box"
to use a predictable size of margins from AdwEntryRow.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/738>
But mark them as not child visible. This should make keyboard
navigation work again, as the focused rows don't change actual
visible state, and thus are keyboard navigatable and don't lose
focus.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/769>
The tick callback can be fired *after* the GtkWidget.map() vfunc is
called, in which case the recalculate_layout_blocks() will run with
an already recalculated layout, which is invalid.
Only call recalculate_layout_blocks() when the blocks are invalidated.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/768>
Create a new GcalEventWidgetPool shared between all month view rows.
The event widgets are distributed to rows as needed.
When rows are done with the event widget, the give them back to the
pool so that other rows can reuse them.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/758>
This is a helper object that preallocates a number of event widget,
and then gives them away to consumers. When consumers are finished
using the event widget, instead of simply destroying it, they can
return the widgets to the pool, so it can be further reused.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/758>
The previous sorter was a simple GcalRange proxy, but we need a more
robust and stable sorting mechanism. Use multiday, start and end dates,
length, and finally the last modified date to sort events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/761>
The current way of adding activation shortcuts is cumbersome,
as it is a for-loop pasted in the middle of class initializers.
The utility function addresses this problem by simply allowing us
to declaratively add these shortcuts with minimal effort.
Furthermore, the implementation is also simpler, thanks to the
`gtk_widget_class_add_binding_signal()` wrapper function.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/747>
GSequence is useful and provides us with a convenient API, however,
it pretty much guarantees cache misses when iterating, lots of pointer
chasing, and scattered memory.
gdkarrayimpl.c works around all of that, at the cost of more expensive
additions and removals. But because we do a lot more lookups compared
to edits, there should still be benefits to it.
Change the backing store to be based on gdkarrayimpl.c.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/757>
There's no point in adding the Agenda view to the timeline when it's
invisible, it just causes invisible and unnecessary event widget
recreation.
Add it lazily to the timeline, when the page visibility changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/757>
Augmented timelines increase the range of dates from its subscribers
by the specified factor. They're useful for the interactive views,
since they prevent fetching new events so often as when views change.
Add the necessary API.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/755>
