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, 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
Dnd at week header crashes with segmentation fault
The problem, calculation of dnd_date returns NULL when week_start is
in previous month.
Fix that by using g_date_time_add_days() function
https://bugzilla.gnome.org/show_bug.cgi?id=781955
The Problem: When user remove 4rt fullday event, header only shows two
events and not shows 3rd fullday event
Because, we check and set visibility of event that user wants to remove
from calendar, before remove event from event list which causes 3rd
event unvisible.
Fix that with check and set visibility of event after remove event
from event list, then visibilties and overflow corretly calculated
https://bugzilla.gnome.org/show_bug.cgi?id=777423
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.
One of the biggest issues of GNOME Calendar views right now
is that they rely on GObject property system to update the
active date. Even gcal_view_set_date() is just a wrapper
around GObject set.
Because GObject asynchronously updates the property by letting
the mainloop handle it, we can never be assured that all the
views had their views updated before updating the data model.
This patch temporarily adds sanity checks to GcalWeekHeader
to prevent making Calendar unusable, until we fix GcalView.
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
When comparing events' dates against week dates, we must
be careful to compare UTC with UTC. Otherwise, some events
will be left, specially at the first and last days.
In this commit, the correct week number is set in week-view.
The problem is, the week number of week-view is being set according to
the first day of the week (if the first and last day of the week
are in the same year), or the first and last day of the week
(if the first and last day are in different years).
To fix this, the week number is being set according to the middle day
of the week (according to ISO 8601 standards), resulting in correct
week numbers.
https://bugzilla.gnome.org/show_bug.cgi?id=779331
The auxiliary functions to calculate the week start
already takes the first weekday into account. We,
however, were considering it again when calculating
the event position.
Fix that by only considering it once, through the
get_start_of_week() function.
https://bugzilla.gnome.org/show_bug.cgi?id=780051
The rudimentary drag n' drop support should also deal
with the following corner cases:
All Day
Multiday | TRUE | FALSE |
|----------|------------|
TRUE | utc | no changes |
FALSE | utc | utc |
https://bugzilla.gnome.org/show_bug.cgi?id=777424
We were using gtk_widget_queue_draw() as a callback to
a GTimeoutSource, which expects a boolean return type.
This is clearly wrong, and has the chance to cause
a segmentation fault.
Fix that by passing a function with the apropriate signature.
https://bugzilla.gnome.org/show_bug.cgi?id=779823
When the first weekday wasn't monday, we were
miscalculating the initial and final positions
of the widgets.
Fix that by properly calculating the initial and
final positions.
