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. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
