On Mo, 2011-12-19 at 10:57 +0100, Chris Kühl wrote:
On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly
> Note that your example code closed the
> connection while the rest of SyncEvolution didn't. This might be
> something that still needs to be fixed.
It seems that this is dependent on how the connection was created. Let
me take a look at this more closely.
Private connections need to be closed, shared must not be closed (?).
Note that the libdbus based code uses private connections for
everything. I think that this was done to avoid some interoperability
issues with EDS using GIO - but memory is hazy on that. Going forward
the old-style code should continue to use private connections while the
new GIO code can be tested with shared connections.
So perhaps the parameter for that can be removed and made a static
choice in the dbus_get_bus_connection() implementations?
> While testing that with GDBus GIO I noticed that I get segfaults
> compiling on Debian Testing and --with-gio-dbus. That happens with and
> without my clean up patches - Chris, can you check that? If you cannot
> reproduce it, then please let me know and I will check it. It's a bit
> strange that I haven't seen that in the nightly testing.
> The signal callback seems to get an invalid std::string:
My testing involved running the test-dbus.py script. I guess this
didn't cover all cases. I'll look into this as well.
Right, another test-dbus.py run passed fine this weekend.
So let me be more precise: a "syncevolution --version" invocation
This is indeed a gap in the nightly testing. I need to add real tests
for syncevolution <-> syncev-dbus-server.
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.