[MeeGo-dev] KCal-EDS: Support local calendar creation
christophe.dumez at intel.com
Thu Jun 9 11:55:28 PDT 2011
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
On Thu, Jun 9, 2011 at 4:29 PM, Dumez, Christophe
<christophe.dumez at intel.com> wrote:
> 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 /
> 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:
> 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).
> On Thu, Jun 9, 2011 at 3:44 PM, Patrick Ohly <patrick.ohly at intel.com> 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
>> 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
More information about the MeeGo-dev