The end goal is to make GcalEventEditorSection require inheriting
AdwPreferencesGroup. Given that most widgets utilizing
GcalEventEditorSection inherit another widget, we first want to
change and adapt the inheritance, and then bump the requirement
of the interface.
These changes will be made incrementally, starting
with GcalNotesSection.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/781>
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>
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>
This is a major rework of the Agenda view. It splits the view into
GcalAgendaViewDay, which represent a single day with events; and
GcalAgendaViewDayRow, which is the actual widget with a title label,
and a listbox with event widgets.
The Agenda view itself merely manages a list of GcalAgendaViewDays,
and updates them with the events model, and active dates.
This allows us to get rid of the custom listbox row, and the confusing
checks for event widgets, and all the bugs the came with it. It also
allows for removing the internal GcalRangeTree, and delegate all
event management to list models.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
And, while at it, rewrite the layout algorithm to operate on blocks of
overlapping events, and segmented columns. Like the month view row,
layouts blocks are invalidated at any point in time, but recalculated
immediately before a relayout happens.
The reason for doing such a massive rewrite while in the middle of the
port to GListModel is because it's easier to handle GListModel data
with this approach, than with the previous approach of storing it all
in a GcalRangeTree.
Closes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1153
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
GLists are an artifact of times immemorial and we should
avoid using them as much as possible. In this commit, for
example, there were a couple of accidentally quadratic
pieces of code.
Port (mostly of) the week view header to GPtrArray.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
