On Do, 2011-07-21 at 02:13 +0200, Ove Kåven wrote:
Den 20. juli 2011 23:12, skrev Roman Morawek:
> Hello,
>
> I have been using SyncEvolution intensively on a Maemo N900.
>
> Right now I have a Nokia N950 with MeeGo Harmattan and the wish to
> continue using SyncEvolution with my private Funambol server.
>
> I spent some time on searching for ways to achieve this but did not succeed.
>
> This is my understanding:
> SyncEvolution supports MeeGo and is preinstalled on the Netbook images
> but seems to be not available on Harmattan?
Hmm. Interesting. I had assumed SyncEvolution would be available on
Harmattan.
No, Nokia wanted to use their own solution, Buteo.
Roman, I haven't followed what Nokia did with Buteo in Harmattan. Which
SyncML servers does it support?
> Are there plans to support Harmattan?
I suppose you might have to wait until I get a N9 - unless someone else
does it first. (Or, I suppose, someone gives me their N950, but I won't
be holding my breath waiting for that.)
I have neither a N950 nor a N9 and no plans to compile SyncEvolution for
Harmattan myself.
> Or is it just a matter of proper installation or compiling the
package?
I'm not sure. I took a look at some Harmattan docs, and it seems that
calendar-backend may have been replaced with "mkcal". Perhaps
SyncEvolution's existing kcalextended backend would work with mkcal. For
contacts, I suspect they now use qtcontacts instead of ebook, so perhaps
SyncEvolution's qtcontacts backend would also work.
Both backends should indeed work with the PIM storages in Harmattan.
Initially, I wrote them to have some way of experimenting with these
storages, later the mKCal backend became relevant for a while for CalDAV
syncing in MeeGo.
MeeGo no longer uses mKCal/QtContacts-Tracker, so both backends are
effectively unmaintained until someone picks them up again. If someone
does, I'd be happy to keep them in SyncEvolution.
--
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.