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
Button sensitivity is automatically updated with action state.
By taking advantage of this we can use the `win.today` action
on multiple buttons without needing to update every button.
For the sake of smooth adaptivity, we need the toolbar buttons
to be constant in both modes instead of moving places from one
mode to another. Instead of duplicating these groups of
buttons, we can refactor them into an object for toolbars
and use them in multiple places.
This commit takes the widgets from the end of the header bar and
creates `GcalToolbarEnd`, which is used in the header bar and the
mobile action bar.
This reworks the style of the event widgets to make them match the
latest designs. This also supports the light and dark theme preferences
and fixes some spacing inconsistencies and errors.
- The orientation of events only affects how their content is laid out,
not their style.
- Events are fully colored accordingly to their calendar's color.
- Timed events have a semi-transparent background and a kind of opaque
knob on their left.
- Timed events have their text colored according to the theme.
- Lasting events are fully opaque, with no knob.
- Lasting events have their text colored according to their calendar's
color.
This purposefully leaves the indentation broken to help reviewing the
changes.
