On Thu, 2004-10-14 at 09:01 +0800, Not Zed wrote: > On Wed, 2004-10-13 at 01:34 -0600, David Trowbridge wrote: > > 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? > > Once you add the stuff to the new-calendar thing to select the type of > calendar, the rest should just follow.
Well, we are in the process of releasing an "out-of-tree" plugin for integrating OBM http://obm.aliacom.fr with evolution. OBM provides contact and calendaring. The code register this kind of connector looks like massive hacks : - we created a camel provider and an empty store to appear in the "server type" combo box in the new mail account wizard, but OBM has nothing to do with email. - we use the provider to setup a listener on the e-account list, and we register 2 ebook-sources, and one calendar source for each OBM user that has a public calendar; This means lots of dirty hacks on the source uri strings and properties - we manually set the e-password for each source we create, because we didn't found a way to properly inherit the one from the account For me it seems like lots of hacks, but it works (tm). Screenshot here : http://dbmjui.sourceforge.net/obm_calendars.png First release (with both server and connector under GPL) expected soon. Regards, Thomas. _______________________________________________ evolution-hackers maillist - [EMAIL PROTECTED] http://lists.ximian.com/mailman/listinfo/evolution-hackers
