Evolution calendar model/view cleanup

I had been working on cleaning up the model/view design last week. This was how it was,

and now it is,

So evolution calendar used to send 5 queries to EDS everytime a date is opened or while switching dates/views. This has been cut down to single query. The query is sent for only the view that is currently shown. The events just remain in the model and as soon as the view is changed, the previous events are destroyed. So if one is in day view, only those events would be in memory.

Initially I thought about storing the events for the dates shown in the date navigator and using it in all other views. But while discussing this with federico during GUADEC, who gave a better suggestion to  keep only the events needed by the view in memory, which is better. As we  query events from a local server (EDS) it should be fast enough. Also with GSoc work getting in soon, it should be just fast!!

With this patch, I can see a noticeable performance improvement in PageUp and PageDown operations in MonthView which michael meeks was very concerned about 🙂

Still more can be done:
Have an interface in ECal to just return the dates which has appointments. This would be useful for all calendar applets (date navigator).

Store just summary of the events in ECalModel as view just needs the summary and information to show the icons. I need to wait for slusny to complete the GSoc work so that I can just get the recurring instances instead of master object to just hold summary of events in evolution.

With ECalComponent and icalcomponent:

ECalComponent is a wrapper to icalcomponent. We use both of them at many places. icalcomponent is structure oriented, while ECalComponent is GObject based. Some things which can be improved here,

Avoid cloning icalcomponent at multiple places. ECalComponent  has issues in managing memory while resetting the icalcomponent, so if one wants to use an API in ECalComponent, we just clone the icalcomponent and create a new ECalComponent which is bad.  Needs some fixing here..

We had some plans for using ECalComponent in all parts of Evolution/EDS hiding icalcomponent, am not sure whether we can still do it  as ECal interface exposes icalcomponent in many places. It would be good to use ECalComponent as its object oriented and so would  help us in avoiding copying icalcomponent structure at many places. ECalComponent would need more API’s for manipulating icalcomponent which is a reason why we use both of them.


One thought on “Evolution calendar model/view cleanup

  1. When is evolution going to see some work on caldav? The current caldav plugin is terribly buggy and hasn’t received updates in a long time. Meanwhile, everyone else in the calendar space (Zimbra, Scalix, Thunderbird, Chandler, Citadel, KOffice, etc…) is working heavily on caldav.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s