The code block for the commit message contains blank characters that are
breaking the markdown rendering engine, making the message block to
stop right after the first paragraph, and getting rid of the last line.
Simply cleaning these blank characters make the code block to render
properly. Note that I've also specified the type of the block, which is
plain text.
The GcalDateSelector returns an internal instance, while the 'until' date/time
is meant to be an own instance, which is freed by the GcalRecurrence instance
in its free function. That means the 'until' date/time is supposed to be reffed
when being assigned into the GcalRecurrence structure.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/892
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
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
