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>
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>
Add a GtkFlattenListModel that flattens out all events from the
calendar monitors. Keep a GtkFilterListModel, and a GtkSortListModel,
for each subscriber. Manually update the filter when the range of
the subscriber changes.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
This is a GListModel implementation that is specific to
GcalEvents. Events are stored in a GSequence in order of
date.
Add a couple of tests exercising additions and removals.
WIP: add more tests
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/742>
