Hi, I have just uploaded kcal-eds v0.1.0 to eds and devel:meego-ux repos. It supports calendar creation and the GConf entries are correctly created so that there is no persistence problem.
Note that based on the feedback from mcrha, I have not patched EDS but instead kcal-eds is taking care of creating the necessary GConf entries. Kr, Chris. On Thu, Jun 9, 2011 at 4:29 PM, Dumez, Christophe <[email protected]> wrote: > 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 > -- 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
