Hi, There is still an issue with EDS. Because the gconf entry is not created, it will keep creating new calendar storages for the same id / uri.
There are two ways to fix this: - Create the gconf entry (either in kcal-eds or in EDS itself) but then Evolution will show it (right?) - Somehow patch EDS so that it reuses the same (file) storage whenever the source uri is the same, even though the GConf entry is not there. I guess this would be better, right? However, I don't know yet how to actually do it. We wrote this patch to create the GConf entry for the local:system: http://git.gnome.org/browse/evolution-data-server/commit/?h=gnome-2-32&id=4c622668652222c6d7817eb5c3c6bbc562073573 but it does not extend to other local uris (e.g. "local:calendar_private"). Note that we have the same problem for contacts if using another address book than "local:system" (default). Kr, Chris. On Thu, Jun 9, 2011 at 3:44 PM, Patrick Ohly <[email protected]> wrote: > On Do, 2011-06-09 at 13:10 +0100, Dumez, Christophe wrote: >> Could you please review the attached patch that implements local >> calendar creation in KCal-EDS? >> >> The apps need to call >> EStorage::localStorage(KCalCore::IncidenceBase::IncidenceType type, >> const QString &id, bool create) >> instead of defaultStorage(KCalCore::IncidenceBase::IncidenceType type) >> to get a local calendar storage. >> >> If the "create" parameter is set to false and the local storage >> identified by "id" does not exist, the method will fail and return a >> NULL pointer. >> The ECal uri is generated from the id provided by the caller as >> follows: "local:<id>". > > Looks good to me. > > Emma, this is meant to be used in the Clocks app. > > Rusty, Ross, note that the created databases are not registered in gconf > and thus can't be discovered via libebook. That may or may not be > desirable. For the Clock app, we certainly don't want Evolution to show > the calendar with the "private" events. > > But how is the alarm notification going to find the private database? > > One possibility is that we establish the convention that local:clock is > the "Clock database", similar to local:system which already (as defined > by EDS) is the system calendar. Then the alarm service can simply watch > these two databases, either because its hard-coded or configured > somewhere. > > -- > Best Regards, Patrick Ohly > > The content of this message is my personal opinion only and although > I am an employee of Intel, the statements I make here in no way > represent Intel's position on the issue, nor am I authorized to speak > on behalf of Intel on this matter. > > > -- Dr. Christophe Dumez Linux Software Engineer Intel Finland Oy - Open Source Technology Center _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
