This patch fixes an issue when creating new events in week view the week
after the daylight saving change.
The problem was in the calc of the selected date, that's done couting
the 30 minutes slots and adding that minutes to the week_start datetime.
When there's a daylight saving change, the real date to select should be
adjusted. This patch adds a new util function to make it easy to add
minutes ignoring the tz so we can make this calc directly with
gcal_date_time_add_floating_minutes.
This also includes a new test file with some checks for the new util
function and spring / autumn changes.
This new function could be used in other places to fix specific issues
that could be caused by the same logic error, calculate a selection or
event position based on GDateTime operations.
Fix https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/482
g_hash_table_lookup() is not transfer-full, so this g_autoptr + the
g_hash_table_remove() call end up double-unreffing the event, which
causes a crash.
Remove g_autoptr from the variable.
When removing the last subscriber (something that can happen when
closing the main window), GcalTimeline clears the event queue. But
that leaves us in an inconsistent state, as we don't process any of
the potentially removed events.
Don't do that.
Related: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1087
Now that GcalTimeline properly notifies about the complete state,
it uncovered an issue where GcalShellSearchProvider was dereferencing
a NULL pointer.
Protect against that.
Don't try and track the number of completed calendars; instead,
recalculate the completed state from scratch every time. This
is not a performance concern, as we're dealing with at most some
hundreds of calendars.
The calendar view thread can start spinning its own mainloop
before g_thread_new() returns, and in that case we have a NULL
thread.
Check that either the GThread is what we expect it to be, OR,
the thread is NULL and there are no messages in the queue.
The notify signals of ESourceSelectable seem to come from the
ESourceRegistry thread, and this has the potential to derail
the execution of Calendar. This might be true for all signals
we connect to.
Make sure to always emit notify signals on the main thread.
Now that we keep precise control over GcalEvent instances, and
can use simple pointer comparisons everywhere, GcalMonthView
implemented its update function as a simple remove + add pair.
The problem is that we're not passing the old event instance,
so removals never actually happen, since the new instance is
not yet available to subscribers.
Pass old event in additio to the new one, and use it where it
makes sense.
Closes https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/1073
This should save quite some resources when manipulating events.
Signals are relatively expensive, and 2 pointer chases are
definitely better than a global lock + FFI stashing + signal
manipulation.
Add a click gesture to detect when we have to start monitoring
cursor motion. Also add a motion event controller to react to
cursor motion, and enable and disable the this motion controller
on button press and release, respectively.
Selection is implemented as a pair of GDateTimes stored in the
month view struct. Whenever a selection begins, the start date
is set; the end date is only set when moving the cursor. It is
valid to have a start of the selection, and no end (meaning, a
1 day selection); it is, however, forbidden to have an end but
not a start.
Future improvements can be added later, such as scrolling when
moving the cursor close to the edges of the month view. We're
gonna have to live without that for now though.
Implement the GcalView.clear_marks vfunc now that we have a
selection to operate on.
