On Sun, 2011-10-16 at 14:11 +0200, stephan0h(a)gmx.net wrote: You want to continue syncing your traditional, local calendar, right? In that case set "evolutionsource" (in SyncEvolution < 1.2) or "database" (in SyncEvolution 1.2 or one of its prereleases) to the name of the local calendar. See "syncevolution" (without parameters) for database names/uris. I guess this will bite more people with CalDAV calendars. Should SyncEvolution prefer local calendars when trying to determine the default calendar? "evolutionuser/password" or (in latest version) "databaseuser/password". -- 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.

On Sun, 2011-10-16 at 23:11 +0200, stephan0h(a)gmx.net wrote: This "Evolution default calendar" must be an Evolution-internal setting. I don't think it is exposed to apps like SyncEvolution via the EDS API. How about "man syncevolution", online at http://syncevolution.org/documentation/syncevolution-usage ? The question is meant seriously. If that isn't written well enough, how could it be improved? There is no explicit example for setting "database", but there is one for setting "sync": syncevolution --configure \ sync=two-way \ memotoo@other addressbook Substitute "sync" with "database", "two-way" with your database name and replace the config/source name with the ones matching your existing config and you are done. -- 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.

On Mon, 2011-10-17 at 20:08 +0000, stephan wrote: The first paragraphs of the USAGE section are meant to explain the SyncEvolution specific terms. For example, "A peer is either a SyncML server (the traditional usage of SyncEvolution) or a client (the new feature in 1.0)". Would it be easier to find this when highlighting the new terms or using a definition list? I also need to check whether all terms are explained well enough. All of these are fair points. Let me try to answer with a revised README sometime this week. Note that it has to be databaseuser and *database*password. Otherwise you end up setting the normal password used to log into the peer. Do you already have the funambol@webcal://something config? The command above will both modify an existing configuration and create a new one, based on the "funambol" template. But a new one won't have a valid username and thus won't be usable. Note that "funambol@webcal://something" gets simplified to "funambol@webcal___something" automatically when storing the config in the file system. You can still reference it via the "funambol@webcal://something" name. Hmm, quite a few automatisms which can be surprising :-/ Your feedback is already invaluable. If you are a developer and want to spend some time on improving SyncEvolution, that of course would also be welcome. -- 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.

On Tue, 2011-10-18 at 08:35 +0200, Patrick Ohly wrote: Attached the result as plain text, man page and HTML. Code changes were made against master in the "documentation" branch; the difference compared to 1.2 is minor (--print-databases is new on the master branch). My goal is to back-port to the 1.2 branch. Stephan, does it make more sense now? It would be very useful to go through this carefully and report all parts which seem odd or are inconsistent. For someone who has written the whole thing it is sometimes hard to spot those. documentation: added glossary and command line conventions sections, improved listing of properties The README.rst now introduces some terms in a glossary directly after the synopsis. The way how config, sources and properties are used on the command line are also defined first in their own section, instead of introducing that further down as part of the options. The output of "--sync/source-property ?" was changed: - now it includes information about aliases, default values and sharing state (useful by itself) - follows reStructured Text format and thus can be embedded directly inside the README.rst -- 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.

On Sun, 2011-10-23 at 15:07 +0000, stephan wrote: Thanks for the feedback. I'm glad it passed muster. I've merged it into the SyncEvolution 1.2 maintenance and the master branches. -- 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.