Read again. I specifically said that's what i have available in the _master_; NOT what i typically sync - that part is probably 10%.

And no, i did not came further along. syncevolution-gui doesn't provide you with the ability to change data stores and their local assignments, if you choose either generic DAV or Google templates. So i would again have to alter config settings manually, scooping through myriads of lines (most of them occupied by comments / commented-out stuff) in several config.ini files.

Btw: wtf, why are there now TWO folders containing stuff for a service, "nameblabla" and "nameblabla-target", stored in a context for DAV? Why does one config file contain "localhost@blabla" as the sync url? This configuration tree philosophy is a mess.

No thanks, i did this once for SyncML, which btw seems the only template / type of sync protocol where you actually have forms available for disabling / enabling partial sources in the GUI, and their sync behavior.

_No_ user should have to wade through this in order to sync different calendars to their respective local counterparts.

Maemo contacts / calendar DB format hin oder her, users should have the availability of a GUI which would enable one to just:

- provide server URL / service / port
- user / pass

(at least in the case of Cal/CardDAV)

then connects to the service and let you either easily link all remotely available stuff to your existing local datastores, or even set this up four you, in that it creates necessary local calendars etc.

In the current state of affairs, it's even worth for me evaluating switching to an Android "phone" as the daily driver in the end, because this PIM stuff affects me probably more than Android's lousy task / background process management.