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.
It is now handled by GcalContext, and no other class uses
the manager's system timezone anymore.
Next step is to get rid of the e_cal_util_get_system_timezone()
calls, but that will require the GcalTimeline API.
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.
GcalManager:remove_event() is an asynchronous function
that, by the time the callback is executed, unreferences
the event that is being removed. This implies that, when
the function was called, a reference was taken -- we don't
want the event to be finalized during the operation, after
all.
The problem is that the reference was never taken.
Fix that by properly owning a reference to the event when
removing it, and dropping it when the removal is finished.
Issue: #268
The first outcome of the test suite. This separation does
not make much sense now, and GcalManager is basically a
holder for all data types.
This commit moves the GSettings to the GcalManager instance
of the application. Of course, in the future, the plan is to
split GcalManager nicely.
Setting 'rid' to NULL in gcal_manager_update_event()
when 'All events' chosen allows us to modify
All and Future Instances of recurrent events correctly.
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
This is a big cleanup commit where I tried my best to
make GcalManager code more structured and readable. This
included both cosmetic and functional changes.
Currently, the user performs a search in Shell and activates
the result. That should show the edit dialog with the event
being edited, but it's not happening correctly.
Debugging the warnings generated, it was found that the event
was being unref()d and, obviously, that was not what we wanted.
Fix that by only unref()ing the events we don't want, and keeping
the wanted event alive.
When we change a source (aka agenda) color, we have to
restart Calendar in order to see it in action.
After the work on GcalEvent, events are now able to track
the agenda's color changes, and the event widget updates
itself in response to that.
The last step was simple notifying GcalApplication when an
agenda changes, so it knows when to recreate the color schemes.
Instead of using the GcalEventData struct, use the
deleted event. It holds a reference until the event
gets destroyed.
With this commit, we can safely drop GcalEventData
structure, since it's not used anymore.
Following the sequence of porting commits, make the Shell's
search provider class handle events using GcalEvent classes
instead of the old GcalEventData structure.
