That is, we'll keep the original values, plus the working values that
get changed from the widgets. We'll use the original values to be
able to reconstruct the original event's duration if needed.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
I want to test that when:
- a one-hour event is loaded
- all-day is turned on
then the start and end date widgets display both the same date.
This fails right now, because we subtract one from the end_date. I'll
change the way the dates are handled so that this magic only needs to
be done when setting back the GcalEvent.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
This clarifies things:
* GcalScheduleValues contains the real data, based initially on the
GcalEvent.
* WidgetState's date_time_start / date_time_end may not be the same as
the real data, since the values get adjusted for display, as in the
case when handling all_day events.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
I think this was being done so that:
- create a new all-day event
- open it in the event editor
- switch to time-slot
- time choosers now say "UTC"
doesn't happen. I think this can be handled more gracefully.
Evolution does not handle it very gracefully; when turning off
all-day in its event editor, it sets the times to $now.
The iOS calendar app is better. If you turn all-day off, it picks
$next_hour_based_on_now for the start time, and $next_hour_plus_one
for the end time. So if you turn off all-day and it is 18:24 right
now, it will set the start_time to 19:00 and the end_time to 20:00 ---
that is, it creates a one-hour event at the next start of the hour
from now.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
For now this is redundant, as update_widgets() only sets the
visibility of the time selectors, while the call to
adw_toggle_group_set_active_name() effectively does the same.
But that redundancy will go away in the next step.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
You may think, yet more indirection! But behold:
1. We take events from the widgets ("schedule type (all-day) changed") and turn
them into actions (gcal_schedule_values_set_all_day()).
2. Those actions (e.g. that function) decide how to change the GcalScheduleValues.
3. We compute the desired state of the wigets, based on the new
values.
4. We set the state of the widgets based on that.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
With this, there's no direct mutation of the self->event anywhere; the
_apply() function just uses self->event as a target for mutation
because that's what the surrounding architecture expects.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
Full month names are easier to notice and read while scrolling,
and would be read more naturally by text-to-speech screen readers.
An exception must be made when today is near the beginning of the month,
as the weather forecast temperatures labels might also appear there.
In that case, use the abbreviated version of the month name label.
Fixes issue #962
ScrolledWindow handles PgUp/PgDown in bubble phase to trigger scrolling.
Which leads to inconsistent behaviour: scrolling when an event is focused,
and moving to the previous/next week when not. Explicitly handling the
shortcuts with a ShortcutController in capture phase makes it consistently
navigate to previous/next week.
Fixes#1409
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/618>
The current behavior of the widget makes it so keyboard focus
outlines the toggle button rather than the entire widget. In some
cases, the outline touches the edges of the label, which makes it
look cramped.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/616>
Read-only events show a "Done" button instead of the "Save" button.
The "Done" button does the same thing as "Cancel",
so the "Cancel" button is then redundant.
Likewise, it is impossible to delete events from read-only calendars,
as stated by the banner message in that dialog. In that case,
there's no reason to show a big "Delete" button that you can't click on.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1168
