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>
"Additive inverse" basically means transforming a positive number
into a negative equivalent, or vice-versa; for example, from 5 to -5.
Instead of inverting conditions in right-to-left languages to
compare the X coordinate, a much simpler approach to this is to
normalize the X coordinate by applying additive inverse in
right-to-left languages.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/744>
When hovering over the bottom side of a month cell regardless of
the sensitivity state of the overflow button, it queries the
button's tooltip text. Using `gtk_widget_set_child_visible()`
fixes that issue.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
Since we don't make use of the overlay anymore, it's best to remove
it altogether.
This also changes the behavior of the widgets a bit: It adds an
empty AdwBin widget which expands vertically, allowing us to avoid
aligning the header and overflow button.
The pattern goes from reducible (where we deduct the overflow
height to retrieve the content) to additive (where we add the
overflow height to the content height), which requires us to
adapt GcalMonthViewRow with this new behavior.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/743>
Only GcalCalendarComboRow, GcalAttendeesSection, and GcalRemindersSection
remain unfocusable on read-only events.
In the case of GcalRemindersSection, we eventually want to allow setting
reminders regardless of the writable state of the event; however, since
dialog is centered around the assumption that a read-only event should
never be edited, which includes reminders, these changes will have to be
done in a separate merge request.
Closes: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/work_items/737>
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/499>
Currently, GcalEventEditorSection is an interface that doesn't
really do much apart from requiring a property and providing
virtual methods.
This proposed approach turns it into an abstract class, derived
from AdwPreferencesGroup, which gives access to virtual methods
as well as public methods. It comes with the same benefits of
an interface, while sharing a lot of code that were duplicated
in the previous commits.
As a stopgap measure, it overrides several GtkWidget virtual
methods to smoothly transition without causing the commits
to break. These overrides will get removed in a later commit.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/711>
This is a preliminary step for moving the comparison and
application logic of each section into the dialog.
Essentially, the dialog will pass the duplicate event to each
section, and these sections will modify the event. If the user
presses "Save", the dialog will compare the edited event to
the original event, and apply if they are different.
This also adds the `get_event()` method which will be used
in the future.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/711>
This adds:
- `gcal_event_alarms_equal()`
- `gcal_event_schedule_equal()`
- `gcal_event_strings_equal()`
We aren't going to make use of it yet, but eventually these functions
will be used for the event editor dialog, as well as writing tests for.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/783>
As described in the previous commit, this approach is more
predictable because the focus is decided in the same place.
The focus grabbing behavior is set after notifying
the `GcalEventEditorDialog:event` property as otherwise it would
not select the entire text in some occasions.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/782>
This will allow for a cleaner and more predictable focus behavior,
as this will give the capability to the dialog to grab focus
on either the "Done" button or summary section depending on the
writability, as opposed to the current approach, where the
summary section assumes that it is already writable and grabs focus,
which then the dialog sets focus on the "Done" button.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/782>
Hari Rana