Re: [HC Evolution] Calendar to-do list

[rms39 columbia edu (Russell Steinthal)]

On Fri, 24 Mar 2000 18:44:31 EST, Federico Mena Quintero wrote:

> 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;

Just for the record, note that this structure has changed in 
gnome-pim since evolution was forked off of the gnome-pim source.  
There was a bug in gnomecal in that there was only one "current" 
pointer into the views, so that all of the views had a common 
"current day," which led to problems when the user used one view to 
move forward or back.  (See bug #2343 on bugs.gnome.org and the 
ChangeLog for 2000-02-21).

I'm not sure if that bug will occur in Evolution's view interface, 
but it would, whoever is fixing the notification mechanism should 
probably also propagate the fix from gnomecal to Evolution.

>          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.

I don't know enough about Bonobo to understand all of the technical 
implications of this, but I can conceive of situations in which it 
might be handy to be able to use only one of the views (and therefore 
it would be useful to have them each be a separate Bonobo object).  
OTOH, since they share a lot of code, it may be simpler just to 
implement some sort of interface for hiding and showing views, so 
that one would import the calendar object and then hide the views you 
don't want.

>       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.

Just a quick note that #3 and #4 are actually related- that is, a 
large part of getting iCalendar "correct" is handling timezones 
correctly...

Also, we need to rewrite the recurrence engine to support iCalendar.  
That should be added to the to-do list.  (Basically, iCalendar 
supports richer recurrence rules than vCalendar, so the existing 
engine isn't sufficient.)


>       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.

I think this is probably a useful addition (and was initially 
thinking of this for iCalendar/vCalendar)...

Speaking of CAP, however, are we planning on providing a CAP server 
interface for the PCS?  That is, allowing other CAP clients to access 
the PCS's event store?

> 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.

I have some sort of intuition, although not entirely thought out, 
that we may be able to do handle this sort of thing, at least in 
part, using the timezone mechanism.  That is, there is going to have 
to be a function call around most (if not all) time accesses in the 
client (to make appropriate timezone conversions)... If a client had 
Islamic support, it could make the appropriate calendar conversion at 
the same time.

There's still the issue of loading and saving, and for that you may 
need an iCalendar extension (or a definition of the Islamic time 
format from the CALSCH folks).

-Russell



-- 
Russell Steinthal               Columbia Law School, Class of 2002
<rms39 columbia edu>            Columbia College, Class of 1999
<steintr nj org>                UNIX System Administrator, nj.org