48be1eb1ff
As first step, notifications and contact data include the new string ID. It is a direct copy of the FolksIndividual ID. The next step is to adapt the ReadContacts() implementation. The change primarily affects notification buffering in the Manager. Not only does it have to remember ranges, but also the corresponding IDs. The Python test now stores either a ID or a dictionary at each view entry. This required changing all comparisons against None, the previous value for "no data". The assertions in ContactsView now use the unittest assertions because they produce nicer error output, and these errors get logged via Python (to make them show up in the D-Bus log together with the other logging of the notification callbacks). As before, the ContactsView class is picked up as a test class with no test members. Request that unittest skips it (will still show up in testpim.py output, though). |
||
---|---|---|
.. | ||
backends | ||
dbus | ||
gdbus | ||
gdbusxx | ||
gnome-bluetooth | ||
gtk-ui | ||
gtk3-ui | ||
syncevo | ||
synthesis-includes | ||
templates | ||
async.patch | ||
client-test-app.cpp | ||
README.h | ||
README.templates | ||
shlibs.local | ||
src.am | ||
syncevo-local-sync.cpp | ||
syncevolution.cpp | ||
testcases.am | ||
valgrind.supp |
The configuration templates in "templates" get installed into $(datadir)/syncevolution/templates. When adding/changing a new server, then only enter the properties which need to be changed here so that the default values can be used for the remaining properties. An icon can be added here for servers. The file name must start with "icon". Server configurations must be kept in sync in three different places: - here (if a server is installed as files) - in SyncEvolutionConfig.cpp's EvolutionSyncConfig::createServerTemplate() - in SyncEvolutionCmdline.cpp's test server configs - in test/test-dbus.py testGetConfigsTemplates() Note that server icons must come with a suitable license that allows redistribution.