This is still not the ideal solution, but now that we have widgetry
that can handle hundreds of thousands of events, no limitations to
the maximum number of events, and no crashes related on the search
engine, we can increase the search range to a broader value and
show more results.
Helps: https://gitlab.gnome.org/GNOME/gnome-calendar/-/issues/624
When I originally wrote the code, I expected to create a new icon
every time that function was called. That expectation changed, but
the code wasn't fully updated.
Use g_value_set_object() instead of g_value_take_object().
Right now, comparing dates with gcal_date_time_compare_date() gives
the exact opposite result of when comparing using g_date_time_compare().
As shown by this patch, this was a source of *many* bugs.
Dazzle is very sensitive to returning empty search results,
and ends up flickering when we pass a search model that is
not yet populated.
Wait for a few results, or for 150ms, before returning the
model.
https://gitlab.gnome.org/GNOME/gnome-calendar/issues/468
The return value is nullable, but gnome-calendar fails to check it.
Because the nullable return value is inconvenient for us, we can instead
add and use gcal_context_get_icaltimezone() to supplement the existing
gcal_context_get_timezone().
We'll also need a function to convert from GTimeZone to ICalTimezone,
gcal_timezone_to_icaltimezone().
Fixes#419
And this finally hooks up the last missing bit from the
search engine: opening events from search results.
All the necessary plumbing is there for extending search
with other commands or results, such as go to date, etc.
This is architectured in such a way that it will
allow us to introduce other searcheable terms in
the future.
All the functionality that in the past was in
GcalManager is now spread across GcalSearchModel,
GcalSearchHitEvent and GcalSearchEngine.
