Apparently the calendar's views hold a live event editor without an
event, and only set an event when one is selected for editing.
I think it would simplify things to only create the event editor when
it is actually needed, with an event - it would avoid these checks.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
This commit does a bit too much, but with these themes:
- Move the recurrence fields into GcalScheduleValues. This was needed
for consistency, anyway, and...
- ... the next step was to make ::changed() work, which actually
required knowing the original and current values of the recurrence as
well as the dates.
- But then, having a field "orig_foo" for each field "foo" starts
getting unwieldy. So, I moved things around:
- GcalScheduleValues has start/end dates and all_day, and the recurrence.
- GcalScheduleSectionValues is new; it has the "orig" and "curr"
values of the previous type. This simplifies memory management
since each field can be freed with gcal_schedule_values_free()
instead of duplicating _free() for each sub-field.
- GcalScheduleSectionValues also has time_format, as a way to
decouple that value from GcalContext. It's not in orig/curr
because it does not pertain the event; it's just a display-related
thing.
- Actually fix gcal_schedule_section_changed(),
gcal_schedule_section_recurrence_changed(), and
gcal_schedule_section_day_changed(). These become simple since they
just look at the orig/curr fields, without having to touch widgetry.
- All test pass.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
The original code from commit 10234653 is
GCAL_RETURN (gcal_date_time_compare_date (start_date, gcal_event_get_date_start (self->event)) < 0 ||
gcal_date_time_compare_date (end_date, gcal_event_get_date_end (self->event)) > 0);
but it doesn't explain why it just checks for the modified event
getting "wider" (earlier start, later end) than the original event.
I don't understand that logic, i.e. why doesn't it just check that the
dates changed.
Still, now that we keep the original date-time in the
GcalScheduleValues, use them to preserve the original semantics.
I'm not sure exactly what to test about this... a test to preserve those
semantics? A test that the function, per its name, returns true if
the days are strictly different?
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/550>
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>
