On Mon, Dec 19, 2011 at 12:08 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
On Mo, 2011-12-19 at 10:57 +0100, Chris Kühl wrote:
> On Fri, Dec 16, 2011 at 3:41 PM, Patrick Ohly <patrick.ohly(a)intel.com> wrote:
> > 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 (?).
Yes this is what the libdbus docs tell us.
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.
I was wondering why these are all private. Now I've at least got a hint.
So perhaps the parameter for that can be removed and made a static
choice in the dbus_get_bus_connection() implementations?
I'm about half way through test-dbus.py and things are looking fine
using the singleton connection acquired by g_bus_get_sync(). so, if my
interpretation of what you're saying is correct, we can just remove
the unshared (btw, using a negative for a boolean value is confusing.)
option and make the gio gdbus always be a shared, singleton connection
and the libdbus connection always be private. Correct?
> > While testing that with GDBus GIO I noticed that I get
> > 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
Hmm. I get SyncEvolution 1.2.1+20111218+SE+3f4f71a (pre-release) when
running that on my Debian Testing install. But we have had different
results in the past on Deban Testing so I'm becoming less and less
surprised by this.