Fellow [1] hackers:
I've finally sat down to work on adding multiple calendar support to
the calendar (see Bug #525) and have now realized how much more
complicated it is than I thought. :)
In case it's not clear from the Bugzilla exchange, my goal is to
allow the calendar views to merge data from more than one calendar
source: most commonly two or more iCalendar files, but there's no
reason it shouldn't also work for any other backends which end up
getting written. The user would have the options to Include
Calendar... and Exclude Calendar... (or something like that) from the
UI, and the Views would update accordingly.
My initial thought was that this would be relatively simple: instead
of a 1:1 relationship between the view and the CalClient object,
give views a list of clients, create a hash table mapping items
(events/todos) in the view to the proper client, and then simply
route the view/client calls appropriately (and iterating over all the
clients when needed, for example on opening). Conceptually, I still
think that's the best approach.
My problem is that the CalClient pointers aren't just confined to the
view (I've been looking at EDayView to start). There's also
CalQuery, GnomeCalendar, and I'm sure a few others which I found and
can't think of at the moment. To change them all would be a
relatively massive patch, and prone to errors.
Another approach would be to modify (or subclass) CalClient itself to
know about multiple calendars; the include/exclude/merge functionality
would then be moved into the PCS, creating what amounts to a "virtual
calendar." In theory, the views could then remain unchanged, and
would never even need to know that multiple calendars were involved.
The downsides would be that the user would lose the ability to
include a calendar in one view but not another (although I'm not sure
one would want to) and we would lose the (theoretical) ability to
connect an Evolution view to two or more PCS's (perhaps on different
machines) simultaneously. Admittedly, the latter is a far-off
possibility and probably has a bunch of other problems, but it would
be cool. :) (If we had a cal-backend-network-relay, though, we could
still do it, or something like it....)
Before I get further into writing the actual patch, I thought I'd
solicit others' opinions. I suspect at least one will be "not worth
the effort," but I think it has the potential to be a cool feature
and it's clearly not a 1.0-blocker. :)
Thoughts?
-Russell
[1] Ok, it's mostly aspirational. I am determined to have my
contribution to Evolution 1.0 *not* be a patch removing my name from
the About box. Hence this message... :)
--
Russell Steinthal Columbia Law School, Class of 2002
<[EMAIL PROTECTED]> Columbia College, Class of 1999
<[EMAIL PROTECTED]> UNIX System Administrator, nj.org
_______________________________________________
evolution-hackers maillist - [EMAIL PROTECTED]
http://lists.helixcode.com/mailman/listinfo/evolution-hackers
