Re: [Evolution-hackers] calendar EPlugin plans
- From: David Trowbridge <David Trowbridge Colorado edu>
- To: Not Zed <notzed ximian com>
- Cc: evolution-hackers lists ximian com
- Subject: Re: [Evolution-hackers] calendar EPlugin plans
- Date: Thu, 14 Oct 2004 02:42:51 -0600
On Thu, 2004-10-14 at 09:01 +0800, Not Zed wrote:
> On Wed, 2004-10-13 at 01:34 -0600, David Trowbridge wrote:
> > Since I obviously haven't communicated my plans properly to everyone,
> > here's a short roadmap of what I plan to do.
> > 1. EConfig-ize the calendar properties window
> > - this is mostly done. Pending some cleanup, I should have a patch off
> > to e-p for review soon.
> > 2. EConfig-size the new calendar window
> > - this is pending UI decision
> > 3. Add some API to allow plugins to register new sources and a calendar
> > component init hook. The goal of this is to allow plugins to detect the
> > absence of and register new top-level sources, similar to the existing
> > migration code. This will make it so new calendar backends can be
> > distributed completely independent of evolution.
> I don't understand why you need this at all?
> Doesn't the e-source-list manage all of these? You should just be
> adding a new source the same way other sources are added, and they'll
> just 'work', wont they?
It sounds like what ought to happen is a separation of source type from
the source groups.
> Once you add the stuff to the new-calendar thing to select the type of
> calendar, the rest should just follow.
> > 4. (maybe) Add some stuff to allow plugins to do size- and position-
> > requests and custom drawing for calendar elements. This would probably
> > only be used for esoteric calendars like weather, where the standard
> > rendering and interaction doesn't really make too much sense for the
> > data.
> This sounds to me to be something more fundamental than should be left
> to 'plugins'.
The idea would be to allow a plugin to override the default behavior.
] [Thread Prev