On 06/09/2011 05:44 AM, Ohly, Patrick 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.
Using the local:clock (and also local:task) convention sounds like a
fine solution to me.
--rusty
_______________________________________________
MeeGo-dev mailing list
MeeGo-dev@meego.com
http://lists.meego.com/listinfo/meego-dev
http://wiki.meego.com/Mailing_list_guidelines
