The view knows its time range, and knows what the
next or previous dates should be. So instead of
calculating the next date manually, ask the views
for that.
GcalManager is basically an object that is shared
among classes that need to modify calendars, while
GcalClock is just a wall clock implementation.
Move it to GcalApplication, so that objects without
access to GcalManager can still access the clock.
Using GLists and GSLists is a bad practice. These data
structures are too much inneficient and GPtrArray has
the advantage of having a free function pointer, so we
can hide the underlying free function from the consumers
of this API.
This also gets rid of another allocation cycle in Month
view.
Nowadays, GcalEventWidget draws the time by itself. This
makes adding a time header pretty much useless.
Fix this double information by removing the time headers
from event listboxs.
When deleting events with recurrence, we want to hide the event
widgets according to the modification type. So that selecting
e.g. subsequent in the modification type dialog hides the event,
and the subsequent ones, truly reflecting the operation that will
happen.
Currently, however, the views don't do that, and only hide the
event that was asked to be deleted.
Fix that by passing the object modification type, and adapting the
views to take that into account.
Currently, on the year view, Saturday and Sunday are marked
as non working days by default, despite the Locale settings and the
fact that in some Countries Sunday and/or Saturday are workdays.
This patch introduces a new function "is_workday" to check
whether a day is a working day according to the territory part of
Locale.
https://bugzilla.gnome.org/show_bug.cgi?id=746927
While dragging and dropping a recurrent event, pop
up the recurrence-dialog to allow the user to choose
the set of events to which the changes should be
applied.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
Don't hardcode month-day order, use g_date_time_format() and
mark the format string for translation and let translators choose
their preferred formats.
This patch also removes context from the existing "%B %d" date
format because it is unnecessary and this allows the format to be
reused by the patch.
https://bugzilla.gnome.org/show_bug.cgi?id=780629
Currently, GcalManager always assumes E_CAL_OBJ_MOD_THIS
when modifying or deleting events. Since we're landing
the groundwork for recurrence management, we can't assume
this anymore.
This patch, then, allows GcalManager:modify_event() and
:remove_event() receive the ECalObjModType instead of
assuming E_CAL_OBJ_MOD_THIS. However, this commit does
not add recurrence support yet, and every call to these
functions are still passing E_CAL_OBJ_MOD_THIS.
https://bugzilla.gnome.org/show_bug.cgi?id=782755
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.
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.
The code in ECalDataModelSubscriber:component_changed() and
:component_removed() was actually duplicated, and we can
simplify the :component_changed() routine by simply removing
and readding the event.
The current Year view drawing routine gathers events
every single time we draw the navigator. This is, to
the best case, slow to death. In fact, this is why
year view's navigator is so memory and processor
consuming.
To fix that, cache the added components and simply
query them at drawing time.
When dragging events around, the cursors show a + as opposed to a
an arrow indicating that the event is being moved. This can confuse
users.
The fix is to tell GTK that the drag being performed is a move.
https://bugzilla.gnome.org/show_bug.cgi?id=774922
The Week view exposed a bug where we had different
CSS selectors for the exact same label. This made
them look inconsistent, with different colors and
paddings.
Fix that by ensuring they all use the same style
class. The Year view drawing code needed to be
reworked a little.
https://bugzilla.gnome.org/show_bug.cgi?id=778391
