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
The only field that views may change using DnD is the start date
field (and, consequently, the end date), and that's exactly what
we must not show the MOD_ALL option for.
Don't show it.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/882
When we receive the 'objects-modified' signal, we get components
that may represent main events. We also may receive components
that have no recurrency because they were just changed from being
recurrent to non-recurrent.
We need to handle all these cases properly.
If the event has no recurrency set, remove any potential old
recurrence instance lingering around. If we're changing an event
with recurrency, make sure the recurrency instances are in sync
with the new recurrency.
Fixes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/881
(or so I hope.)
We'll start accessing the hash table from multiple threads, so
it must be in the shared section of the structure, and it must
be encapsulated by locking.
Every once in a while when I'm deleting an event gnome-calendar crashes.
I dug in a bit, and it seems the reason is
adw_toast_overlay_add_toast takes ownership of the passed in reference.
This is a little idiosyncratic for something that's not GInitiallyUnowned,
but it appears to be the API nonetheless.
GCalWindow assumes it owns the reference.
This commit makes both users of the toast happy by adding a ref call.
Every event in RTL languages is drawn in the
wrong place. As a result the week view is totally unusable.
Fix this.
#817
Signed-off-by: Yosef Or Boczko <yoseforb@gmail.com>
When running under valgrind, it claims that there's used uninitialized
memory, which is set as GObject property in the code. It's for
GtkLabel::xalign. The problem was that the value in the code is
an integer, but the property itself expects float type. This fixes
the place and where a floating point is already used it annotates
the value to be float, not a double.
Cannot use g_clear_pointer() here, because it unsets the pointer first and
only then calls the free function, which means the test on self->delete_event_toast
NULL-ness would be satisfied in the on_toast_dismissed_cb(), thus the previous
event delete attempt would be "cancelled" internally.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/858
Georges Basile Stavracas Neto