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>
This is future-proofing the uncertain decision of removing
GtkWidget's `margin-*` properties in the future, which is what
we're currently using to retrieve the height of certain widgets.
Whenever the intention is to get the entire size of a particular
widget, including properties that contribute to layout such as
margins, the `get_width()`/`get_height()` methods don't include
these properties during calculations. However, getting the size
of the parent widget will include them in its entirety.
As such, the safest path is to use AdwBin as the parent to the
respective widgets, and using it to retrieve the height.
See: <https://gitlab.gnome.org/GNOME/gtk/-/issues/6556#note_2056432>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/739>
`hide()` stopped working since we ported to AdwDialog. We certainly
don't want to override the `close()` virtual method from AdwDialog,
as page transitions begin while the dialog is closing. Instead,
we can override `unmap()`, which will do it at the very end.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/712>
When opening the event editor dialog as a new event, `set_new_event_mode()`
immediately tries to focus the last focused widget, which won't work
because it is unfocusable. `focus_last_focused_widget()` then clears
clears the pointer regardless of whether the widget has successfully
grabbed focus or not. So, we want to only clear focus if the widget
has successfully grabbed focus.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1566
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/730>
The event popover contains a lot of text in different sizes, which
pushes us to magic-number the maximum amount of characters
(i.e. `max-width-chars`) and hope that all is well.
This approach addresses that by simply clamping the parent widget
to the desired size, allowing us to remove all instances
of `max-width-chars`.
Do note that `Adw.Clamp:tightening-threshold` is set to 400 by default,
which technically doesn't need to bind to `Adw.Clamp:maximum-size` at
the moment, but I decided to do it anyway in case we want to change
`Adw.Clamp:maximum-size` in the future and can't figure out why
the margins are off.
Co-authored-by: Jamie Gravendeel <me@jamie.garden>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/728>
This fixes an issue where pressing Shift + Up/Down while focused on the
overflow button will result in a bail out when asserting the focused
widget has a month cell ancestor:
```
GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
Bail out! GcalMonthView:ERROR:../src/gui/views/gcal-month-view.c:1002:on_key_controller_key_pressed_cb: assertion failed: (GCAL_IS_MONTH_CELL (month_cell))
```
When navigating between month cells with a keyboard, focus is set
on respective month cells, so checking whether the ancestor
is a month cell or not is not only unnecessary, it also causes
bugs like the assertion above.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/720>
Georges Basile Stavracas Neto