On Thu, 2004-10-14 at 02:42 -0600, David Trowbridge wrote: > 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.
Yes, that is my thought as well. > > 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. This might be a good long term idea, but I'm not sure this should be before two things happen: 1) Rodrigo's recurrence branch code is finished and merged to HEAD (this will alter the e-cal-model) 2) The drawing code is cleaned up, its a giant 20000 LOC mess right now. -JP -- JP Rosevear <[EMAIL PROTECTED]> Novell, Inc. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
