Using raw integers forces us to select a pre-defined
start and end ranges for the timeline. Since we want
to reuse this data structure on GcalTimeline, make it
a bit more useful.
The method ask_recurrence_modification_type() currently
receives an ESource, and tried to fetch the ECalClient
from the ESource by using g_object_get_data().
However, since we moved to GcalCalendar, we do not set
this data field in ESource.
Receive a GcalCalendar instead, and use the appropriate
function gcal_calendar_get_client() instead.
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.
Event dates are, by definition, inclusive on their
start dates, but exclusives on their end dates. That
means that end dates don't actually contain the date
they represent.
Week grid code, however, was considering that end date
as inclusive, and the layout code was miscalculated
because of that.
Fix that by using an inclusive end date when calculating
the event span. Since Calendar does not support subsecond
precision, we do that by subtracting one second from the
exclusive end date.
Issue: #279
The current GcalEventWidget implementation is a direct
GtkWidget subclass, which means we have to take care of
all the implementation details such as raising GdkWindows
and managing the drawing all by ourselves.
The event widget, however, can be easily described through
a GtkBuilder file. This would simplify the implementation
and makes us maintain less code.
Fix that by making GcalEventWidget a GtkBin subclass.
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.
The week view can display mutilple events that can partly or fully span
same time ranges.
But week view fails to make correct assumption about the width of events when
two or more events span some time ranges in which these events also span some
time ranges with other events, and whereby the number of these other events
that they span time ranges with does not coincide with the number of the events
that the other event also span. Week view ended up calculating cells that
appears horizontally jointed up. Also int16_compare() does not dereference the
pointer from g_ptr_array_sort() correctly and that makes it sort events
incorrectly and hence making events appears vertically jointed up.
If an event have other events in which they span some time, we calcuate its width
by taking into consideration of all the events that the other event may span
time with. The event that has the higher number of time spans is considered.
We also save and retrieve our positions using UINT_TO_POINTER and POINTER_TO_UINT()
respectively, and then dereference the pointer from g_ptr_array_sort() correctly.
https://bugzilla.gnome.org/show_bug.cgi?id=777416
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
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
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.
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
As the assignment of display-text, and in turn that of event-widget's height,
is taken care of in event-widget, we no longer need to consider natural-
height, while assigning height in week-grid.
This patch fixes this issue by removing natural-height, and directly
assigning the desired value to height.
https://bugzilla.gnome.org/show_bug.cgi?id=778070
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
There are some weird cases around the globe where the timezone
changes in the middle of the day. In GMT-8:00, for example, the
DST changes at 2:00 am. This makes the timezone of thestart of
the week different from the event's timezone, and somehow the
GLib API doesn't take that into account when calculating the
diff between two dates.
Fix that by also considering different timezones when calculating
the event start and end positions.
https://bugzilla.gnome.org/show_bug.cgi?id=780079
Sometimes, we'll need to ignore the reported minimum sizes
to be able to set the width of events to an acceptable
size. This is the case of the week grid.
https://bugzilla.gnome.org/show_bug.cgi?id=780052
When adding an event with the same start and end dates and
times, the event effectively spans 0 minutes, leading a division
by zero and causing varius UI glitches.
Fix that by making sure events span at least 1 minute.
https://bugzilla.gnome.org/show_bug.cgi?id=777414
When two or more events overlap, the week grid almost
does the right thing and correctly calculates the width
of the events.
It fails, however, in calculating the position of the
events.
This commit introduces a simple yet efficient way to
position the events. It uses a temporary range tree to
efficiently store already positioned widgets, and checks
for their indexes looking for a hole to position the
new event.
