Reading time format from the settings portal during context init results
in interacting with xdg-desktop-portal before GtkApplication can
register the host app id. This makes portals not aware of the
application id, which could cause problems in the future.
Fix that by calling read_time_format during gcal_context_startup, which
is called after the GtkApplication startup chain-up.
Part-of: <https://gitlab.gnome.org/GNOME/gnome-calendar/-/merge_requests/586>
Creates a chooser managing a GDateTime. The chooser allows the user
to change the date, the time and the timezone independently.
This replaces the precedent GcalTimeChooserRow widget, because it is
easier to manage the different interactions with the user in a single
widget.
Co-authored-by: Georges Basile Stavracas Neto
<georges.stavracas@gmail.com>
When dealing with floating time events the timezone used was UTC,
but according to RFC5545 when the timezone is not specified the
local timezone should be used.
Fixes#171
Timeline subscribers (i.e week_view, month_view, agenda_view, date_chooser) were not
properly notified of event(s) moved out of their listening ranges.
We notify them to remove these events.
fixes: #994 and #1043
This patch do not sends ADD_EVENT for events that are multiday and are
part of the old_range when calling calculate_changed_events. This will
prevent multiday duplicate events to appear in the agenda widget when
using the week view.
If the event is a multiday and it was in the previous range, it won't
send the REMOVE_EVENT so multiday events won't dissapear when it's still
relevant.
See https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/898#note_1602391
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.
