[HC Evolution] Calendar to-do list

[Federico Mena Quintero <federico helixcode com>]

Dear primates,

Here is the list of things that need to be done to the Evolution
calendar:

        1. Use the new notification mechanism for all views.  What we
           have now is a toplevel calendar window, represented as an
           object called GnomeCalendar, that contains multiple views:

                typedef struct {
                        GnomeApp app;

                        CalClient *client;

                        GtkWidget *day_view;
                        GtkWidget *week_view;
                        GtkWidget *month_view;
                        GtkWidget *year_view;
                } GnomeCalendar;

           The client field is the CalClient interface used to talk to
           the personal calendar server.

           And then we have these functions

                void gnome_calendar_add_object (GnomeCalendar *gcal,
                                                iCalObject *ico);

                void gnome_calendar_remove_object (GnomeCalendar *gcal,
                                                   iCalObject *ico);

           which basically add the specified object to the store and
           notify each of the views to update themselves via this
           function:

                void gnome_calendar_object_changed (GnomeCalendar *gcal,
                                                    iCalObject *ico,
                                                    int flags);

           Here, ico is the object that changed and the flags were
           intended to specify what had changed in the object:
           whether it was a new object, or whether just some fields
           had changed.  We never made much use of this field.

           However, this function is essentially implemented as

                void
                gnome_calendar_object_changed (GnomeCalendar *gcal,
                                               iCalObject *ico,
                                               int flags)
                {
                        gncal_day_panel_update (gcal->day_view, ico, flags);
                        gncal_week_view_update (gcal->week_view, ico, flags);
                        month_view_update (gcal->month_view, ico, flags);
                        year_view_update (gcal->year_view, ico, flags);
                }

           (The code is not really like that, but that's basically
           what it does).

           This sucks.  Everything gets routed through that function
           and a lot of unnecessary updating is performed on all
           views, even when they are not visible.  Moreover, this
           makes views have an ugly API.

           I am changing the views so that they simply connect to the
           notification signals of the CalClient object.  This lets
           them update themselves when they need to, and only if they
           know they are visible.  It also makes the code flow much
           simpler and easier to change.  While I'm at it, I'm
           integrating Damon's beautiful day view into the code and
           dropping the old widget from Gnomecal.

           This should also let us rip apart independent views and
           embed them somewhere else.  I am still not decided if we
           want to export the day/week/month/year notebook combination
           as a Bonobo control for the Evolution shell, or if we want
           to have something more fine-grained, i.e. separate
           components for each of the views.  I don't know if we want
           to change menus or toolbars depending in which view is
           active.  I'd like to know what Outlook does, but I'd also
           like to keep the interface simple, since people seem to
           like the way Gnomecal works.

        2. Implement saving in the personal calendar server.  This is
           basically pasting about 10 lines of code from the old
           Gnomecal sources, plus some extra code to save things
           periodically, perhaps in a timeout, if things have been
           changed in the calendar.

        3. iCalendar support.  We need to suck in an interoperable
           way, i.e. we need to support all the fancy stuff that
           iCalendar defines.  This involves some stuff that has to be
           done carefully, such as updating the revision number of
           calendar objects when they change.  Read the iCalendar
           specification and weep.

        4. Proper timezone support.  What we have now is very crummy.
           Russell said he wanted to work on this, and he seems to
           have a good understanding of the issues involved.

        5. Finish the GUI overhaul with Damon's new widgets.  As a
           side note, MS now has a "digital dashboard" thingy.  Among
           other things, it presents you with a very nice view of the
           things you have to do today:  your important incoming
           mails, your to-do tasks that are due today or soon, today's
           appointments, etc.  We may want some nice views for such a
           thing as well.

        6. Make the personal calendar server support the concept of
           providers, possibly in a similar way to how Camel does it.
           We would then have a vCalendar provider, an iCalendar one,
           a CAP one, and LDAP and all that scary stuff.  

           Right now the initial iCalendar support simply has a flag
           in the calendar store that says whether it is a vCalendar
           or an iCalendar.  This is somewhat bogus, and providers
           would make things simpler and more extensible.

        7. In the PCS, we need to store a log of changes to the
           calendar.  Eskil and I came up with this during GUADEC;
           with such a thing we can do several things:

                a. Implement proper deletion support for Pilot
                   synchronization.

                b. Remove all knowledge of the Pilot and other PDAs
                   from the personal calendar server.

                c. Provide a separate CORBA interface to access the
                   log of changes; we would have a registration and
                   expiration mechanism so that interested parties can
                   tell the PCS that they are interested in looking at
                   the log at a later time.

        8. Finish documenting the Bonobo/CORBA interfaces.  I have
           docstrings for the GTK+/Bonobo wrappers, but not for the
           base CORBA stuff.  Write the programmer's documentation and
           the explanatory part of the API reference.

        9. Write the user documentation.  The current Gnomecal section
           in the GNOME User's Guide is a very good start.

        10. Modify the interface with the PCS to be fully
            asynchronous.  This is mostly grunt work.

        11. There is no number 11.

I'm doing (1) and (2), with (1) being my main focus right now.  Seth
did the work of making the current Gnomecal codebase know about the
CalClient interface, and I'll just finish the notification code.

I asked Seth whether he wanted to work on (3), since he was working on
iCalendar initially.

Russell wanted to do part of (3) and most/all of (4).

Damon is of course doing (5) and providing eye candy for all of us :-)

I would like to talk to Bertrand and Nat about (6).

Eskil said that he would start working on (7).

I can do (8), since sometimes I pop and become a documentation writing
machine.

Aaron may want to look into (9), coordinating with Dave.

I'll do (10) if nobody else is terribly excited by asynch stuff.

As another side note, Ali Abdin said he wanted to investigate adding
support for other types of calendars, such as the Islamic calendar.
This is a bit tricky; there has been some discussion and JWZ suggested
looking at the Emacs calendar and some excellent reference material in
a book about calendarical computations.  It is also tricky because
iCalendar only supports Gregorian calendars right now, so we may have
to talk to the IMC's working group on calendaring.

That's all I can think of for now.  Please comment.

As the third side note, I am very happy to have so many excellent
hackers working on the calendar.  Evidently people need a way to
organize their lives :-)

  Federico