g_strcmp0() is used when comparing the display name of the ESource.
This is not a valid sort, because in this case we will get an order
like "a" < "z" < "B" < "Z", but it should be like "a", "B", "z", "Z".
We will use g_ascii_strcasecmp to fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
g_strcmp0() is used when comparing the display name of the ESource.
This is not a valid sort, because in this case we will get an order
like "a" < "z" < "B" < "Z", but it should be like "a", "B", "z", "Z".
We will use g_ascii_strcasecmp() to fix it.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
Since gcal_manager_get_sources() returns a GList of ESource received
from the hash table, they are not sorted alphabetically. Because of
this, edit-dialog shows the unsorted list.
I added a function for sorting this GList that is case-insensitive.
https://bugzilla.gnome.org/show_bug.cgi?id=781231
Valgrind was reporting some "Conditional jump or move depends on
uninitialised value(s)" and "Invalid read of size 4" when hovering
year-view.
It was found some uninitialised variables in the code and they were
initialised before being used.
https://bugzilla.gnome.org/show_bug.cgi?id=781430
By storing the coordinates array in a local pointer,
we avoid 9 super slow full memory lookups. That matters
when we're inside the drawing function, trying to keep
60fps.
There was a typo in function name, which was only setting
the upper bound for 24 hour time format. As the default
lower bound is 0, no issue was known so far.
But in cases like the user switched from 12 hour to 24 hour
format there is a chance for some issues to appear as the lower
bound of 12 Hour format is 1, and it won't be reset to 0 when
the user has switched to 24 hour format.
https://bugzilla.gnome.org/show_bug.cgi?id=781448
The function is supposed to run once every minute. So after
the function is run, just remove it from main thread. So that it won't
act as a time bomb.
https://bugzilla.gnome.org/show_bug.cgi?id=781081
The current implementation is deficient in many ways, the
worst one being the it relying on GObject semi-synchronous
property emission.
This issue was exposed by the Week view code, where the active
date was updated, but delayed to reach the Week header and some
events were being added ~before~ the active date changed.
With this work, I was also able to figure out a bunch of code
that relied on this (i.e. luck) to work.
In month view and year view, when the mouse is hovering over
an event, nothing is shown. A tooltip with the event information
would be much more useful in this scenario.
Fix that by showing a tooltip displaying the event's title, time
and date, and, if present, the location and notes of the event. Long
notes are truncated and ellipsized.
https://bugzilla.gnome.org/show_bug.cgi?id=774952
On RTL languages, the calcs to detect the start and end
of the new event were wrong, leading to the weird behavior
it currently has.
Fix that by correctly calculating the start and end cells
on RTL languages.
https://bugzilla.gnome.org/show_bug.cgi?id=777429
