created configuration incomplete when using SyncEvolution 0.8

[Patrick Ohly]

I just tried out 0.3.1, in particular to found out whether it works with 0.8 (which I'm currently about to release, at least as beta 1).

The GUI for creating new configs is really slick, I like it a lot. However, the resulting configuration in ~/.sync4j/evolution turned out to be incomplete: the only fields which were set at all were those selected in the GUI. All the fields which should have had default values were missing, including some of the required ones (uri, type).

Without having looked at the source code I guess that Genesis tried to copy one of the example configs, didn't find them in the expected location and then proceeded without them.

Frederik, do you have plans to update Genesis to 0.8? I'm sure that this would be very much appreciated by your users. There are other issues in combination with 0.8, for example a configuration created with the new syncevolution command line in ~/.config/syncevolution is not found.

[Frederik Elwert (frederik-elwert)]

I haven't tested with 0.8 yet at all.

The reason for the incomplete configs is probably just what you described. I'll have to take a look at how syncevolution 0.8 handles the config stuff now, and I'll update Genesis accordingly. Maybe I'll even provide a whole new backend that talks to syncevolution only using the command line, and keeping the old config file based backend only for 0.7 users for some time.

I hope I'll have a new version that can deal with syncevolution 0.8 by the time it will be released.

[Patrick Ohly (patrick-ohly)]

Excellent, thanks a lot Frederik.

If you need changes or additions to the command line arguments, then please let me know.

One more comment: do you think you can remove the hard dependency on python-evolution + python-notify? I tried to get Genesis running on the Nokia N810, but it doesn't have these two modules. python-evolution could be replaced with suitable invocations of syncevolution. Not sure what pynotify is needed for, though.

After removing these two it still misses python-configobj (configobj and validate) and python-xdg. Perhaps these dependency could also be avoided by not reading/writing config files directly? Hmm, I see that they are also used to read/write the Genesis settings themselves.

After uncommenting all code which currently uses unavailable Python modules I got the Genesis icon to show up in the Maemo GUI. I can click it, but because I don't have a right mouse button on the touch screen I wasn't able to test whether any of the additional dialogs work. A "left" click starts the icon animation; I haven't checked whether it does anything useful.

To summarize: if some of these dependencies become redundant by changes that you want to make anyway, then go for it. Otherwise I suggest that you don't bother yet.

[Frederik Elwert (frederik-elwert)]

I hope I get Genesis to work with syncevolution 0.8 this weekend.

For the dependency issues: I'll see what might become obsolete when upgrading to 0.8. For the remaining modules (which I hoestly expect to be the majority) one might set up a new source branch and try to get Genesis slim enough for the Nokia device.
I'd recommend opening a new bug report then for Genesis on Nokia where we could discuss these issues.

I guess most dependencies could be replaced using only standard python modules. I had focussed on as little work as possible, not as little dependencies. But some parts might be harder to work around, esp. the lack of right-click and the lack of libnotify (which is used to report the result of the sync).

[Frederik Elwert (frederik-elwert)]

The fix for this is now in the new-config branch. Feel free to check it out and test it. But please notice that this branch will only work with syncevolution 0.8, not with 0.7. I decided to make Genesis 0.4 backwards incompatible, but I'll maintain the 0.3 series for a while for the syncevolution 0.7 users.

[Patrick Ohly (patrick-ohly)]

I have tried out the branch. It worked fine, including setting up multiple sources.

In the template selection I noticed that it offers "custom server". When using that option it is possible to override the syncURL of the default template (guessing from the result). This option has the potential of confusing novice users: in many (most?) cases, the URI of the sync sources will be wrong.

I'm not quite sure how to handle this. Possible solutions are:
* don't offer the option
* add a column to the sync source selection where the user can enter the server URI as string in addition to enabling/disabling and selecting the Evolution source

[Frederik Elwert (frederik-elwert)]

You're right. I hadn't really thought about it, as I didn't use this option for myself. I just thought it would be nice not to be forced to use one of the pre-defined servers (e.g., when using a local SyncML server).

Also, I read that this could be used to sync additional sources by using a dedicated syncurl for the resource: http://wiki.scheduleworld.com/wiki/Evolution_Configuration#Syncing_Multiple_Calendars

I now made a first try fixing this. When giving a custom server url, an additional entry is added for specifying the source uri.

But maybe this could be solved more elegantly. Any recommendations welcome.

[Patrick Ohly (patrick-ohly)]

Specifying a sync URL can be useful, so my suggestion would be to offer it in *addition* to selecting a config template, not *instead* of it, as it is done right now.

Use cases:
* private Funambol installation
* ScheduleWorld with non-default calendar

In both cases the URIs are the same as in the normal config of Funambol resp. ScheduleWorld, but the syncURL has to be changed.

In the GUI that could be solved via an additional checkmark, off by default: "Override default values". If and only if that is selected will it be possible to edit syncURL and URIs. The default values from the selected template should be used to prefill these additional text fields. Hopefully novice users will recognize that the defaults will work for them.

That's the problem with the checkmark: one doesn't know which default it controls. Perhaps it would be better to not offer the checkmark and simply always offer the possibilities to edit syncURL and URIs.

[Frederik Elwert (frederik-elwert)]

I have pushed a new version to the new-config branch. Could you have a look if this is what you meant?

I am much more satisfied with this solution that with the previous one, your absolutely right. Thanks for your suggestions!

I am currently updating the translations, and I plan to release a first public beta in the next days. If you stumble about problems that should be resolved first, please leave a note.

[Patrick Ohly (patrick-ohly)]

Yes, this is what I meant. I only have two minor suggestions: I think the "Custom Server" option is no longer needed. That selecting one of the predefined settings is really just choosing default values which all can be overridden, can be made more obvious by putting a "Config template" (or if you prefer that, "Server template") in front of the drop-down list.

[Frederik Elwert (frederik-elwert)]

Right, I also thought about the label. I'll probably add it in the final.

Regarding the Custom Server: I know that this is redundant. But I think it makes it more obvious that one is not restricted to use one of the pre-defined servers. And it doesn't hurt. So I wanted to keep it for now. Maybe I change my mind in the future...