Visually, this comes with the benefit of not having the first
and last visible event widgets take additional margins, as spacing
is only applied between event widgets.
This will also allow us to make use of gtk_widget_pick() without
having to rely on hardcoding 1 on the y axis.
The current approach has a one pixel margin at the top and bottom
of each event widget, which offsets the vertical position of
every event widget by one pixel. In order to pick the first
event widget, we'd want to call
gcal_month_cell_get_header_height() because this is where the
first event widget is placed. If we were to invoke
gtk_widget_pick() with (x, 0), where x is
half the width of the month cell, the returned value would be
NULL because gtk_widget_pick() does not account for margins,
so it would need to be (x, 1), with 1 hardcoded.
Since this patch removes that offset, we can simply use
(x, 0) without having to hardcode 1.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/813>
For unknown reasons, the `::row-activated` signal is not emitted
whenever the user presses an activation button on the keyboard
such as Enter or Space, even though the list box row has focus.
Ideally, we want the list box rows to be activatable, so that
activating them will simply emit the "event-activated" signal and
pop up the popover.
Since this doesn't work, the next best thing is to make the event
widgets themselves focusable and the list box rows unfocusable.
This will unfortunately lose the ability to navigate with arrow
keys, as well as Home/End and Page Up/Down. However, the user will
at least be able to activate them and access events in
the agenda view.
A `FIXME` label has been added because this should be fixed as soon
as possible.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/807>
`WITH_CXX_BINDINGS` is deprecated in libical 4, so it's replaced with
`LIBICAL_CXX_BINDINGS`.
`LIBICAL_JAVA_BINDINGS=False` is required for libical 4.
Since we use `ENABLE_OAUTH2_WEBKITGTK4=OFF` in evolution-data-server,
we could also use `ENABLE_OAUTH2_WEBKITGTK=OFF` alongside.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/811>
For a while, we have been setting child visibility to false, which
hid the horizontal line separators. However, I started scrolling in
the month view today and came to realize that they were disappearing
sporadically when scrolling upwards.
This happens because we use the `box-shadow` CSS property to apply the
box shadow a pixel above the month view row, which keeps it visible
in the view even when the month view row itself is no longer in
the page. Adding a pixel fixes that.
This reverts commit f4702dde1f.
Fixes a few problems in the schedule comparison code:
- Same recurrence pointer short-circuits to TRUE: a pointer to the
same recurrence is not a sufficient condition, because the dates
could still be different (this is especially true if the recurrence
is NULL for both events, but also holds if that is not the case).
Also deleted the explicit check if only one of the recurrence
pointers is NULL, because that is the first thing that is checked
in `gcal_recurrence_is_equal()` anyway.
- Date comparisons only check if the date moved into a specific
direction: the correct logic is to check if they are not the same,
no matter in which direction the date moved.
- The time is not compared: for non all-day events, it is necessary
to compare the time values too. The glib function that is now used
for that also checks the date, so these checks can be collapsed
into one.
For the second and third point it seems like some things got a bit
mixed up in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/commit/2ee6dfc5e7bd5823bee5029a7ac3a32d3c247ba9:
- The `gcal_schedule_section_changed()` implementation already used the
`g_date_time_equal()` function (which is now used again).
- It was `gcal_schedule_section_day_changed()` which only compared the
dates using `gcal_date_time_compare_date()`, but this function was
only used for edits to recurring events to determine whether to
allow changing all instances. This commit now exposes a regression
in this part of the code, which is tracked separately in
https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613.
Fixes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1612>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
See: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/1613>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/792>
Bjørn Mørkedal