Currently we only show writable calendars in the calendar row, but
for read-only events, the read-only calendar must be selected. But
that's impossible because it's not in the model.
Change the model to a flattened list as follows:
+ FlattenListModel -----------+
| |
| + writable calendars -----+ |
| | | |
| | - Calendar 1 | |
| | - Calendar 2 | |
| | - Calendar 3 | |
| | [...] | |
| | | |
| +-------------------------+ |
| + read-only calendars ----+ |
| | | |
| | - Calendar 1 | |
| | [...] | |
| | | |
| +-------------------------+ |
+-----------------------------+
The read-only calendars list only ever has 1 item: the calendar
of the current event, and only if the event is in a read-only
calendar.
Using a tooltip to inform when the calendar is read-only won't
work in touch devices.
This change also improves a11y, as Orca now reads this message,
something that wasn't happening before.
Use the widget to display calendars and distinguish whether
they are visible or not. Currently, it does not distinguish
read-only calendars, but once !494 is merged, it should not
be a problem.
When the alarm sound changes, the change is not updated because
gcal-manager does not see the changes.
We now update the components and make more comparisons so that
it can be seen by gcal-manager
In commit 1494f7407, we focus the summary entry when opening the dialog.
However, this prevents the Escape keyboard shortcut from working
when opening a read-only event after having opened a writable event.
Set focus onto the "Done" button when showing a read-only event,
as it's the only widget that can be activated/clicked in this situation.
This makes the "Escape", "Spacebar" and "Enter" keyboard shortcuts work.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1180
Use a GtkListBox and bind from the model. Create rows from the model
items, and bind properties as needed.
The action target is set only when the calendar is writable because
setting an invalid action+target pair makes the row insensitive.
Remove the ancient menu icon hack.
- Fix a bug where clicking the "Add Event" button created an empty title in the event editor dialog.
- Add "error" class when the user writes an invalid event name.
- Add new function to validate event name.
Because the sections are split into files, the event editor will need a signal to check that each section is correct, and each section will have to emit the signal. This will need to be done in a future commit.
The "Done" button was apparently meant for read-only events,
while the "Save" action was for everything else.
It didn't work correctly because of a mismatch between code and UI XML.
Fixes: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1142
GtkDialog is being deprecated. Instead of using it,
we want to subclass AdwWindow. As part of this change
the content and headerbar are put together in one box.
When a recurrent event is edited, we now are able to only offer the
MOD_ALL option when it actually will work. However, we're still left
with the problem that we end up applying the instance-specific data
onto the main event, through an old hack.
The views already aren't able to offer the MOD_ALL property, since
they all change the dates of events, but GcalEventEditorDialog can,
and it must handle that properly.
For now, do the simplest possible approach, which is: retrive the
template event and apply all properties that can be applied to it,
without letting the start and end days leak into it. We already only
allow passing MOD_ALL on situations where the dates aren't really
modified, so it should be safe.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
We get into seriously tricky situations if we try and change the
date & time of an event with recurrency, and pass MOD_ALL. That's
because it is ambioguous *where* the change must be applied.
Don't allow selecting MOD_ALL when the scheduling of the recurrent
event changes.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
This drops the transient_size_allocate_cb() callback function that in
practice does nothing at all. This also fixes an error message as the
size-allocate signal doesn't exist anymore in GTK 4.
Using dialog responses to communicate intent to GcalWindow was always
a hack, and as the code is cleaned, it's getting increasingly annoying.
Replace this with a proper 'remove-event' signal ('delete-event' would
conflict with the equally named GTK signal), remove the custom response
types, and cleanup the code.
