[Development] QtDBus Improvements

[Andreas Hartmetz]

On Tuesday 30 September 2014 04:49:21 Thiago Macieira wrote:
> On Tuesday 30 September 2014 12:22:26 Daniele E. Domenichelli wrote:
> > Hello all,
> > 
> > 
> > At Qt Contributors Summit 2013 in Bilbao we discussed some
> > improvement> 
> > to QtDBus:
> >  http://qt-project.org/groups/qt-contributors-summit-2013/wiki/QtDBu
> >  s_CS> 
> > I offered to help, but unfortunately I had some important family
> > issues and I couldn't find the time to work on it, since then.
> > Anyway from now on I should have some free time to work on Qt (not
> > much, but better than nothing). Therefore I'm now renewing my
> > offer.
> > 
> > So, are these improvements still in the plan for QtDBus? Has anyone
> > else been working on them? Where can I start?
> 
> Hi Daniele
> 
> Yes, those are still the targets and so far no work has happened.

Hey, that is not true!

I am working on this http://quickgit.kde.org/?p=dferry.git with the
goal to get to an abstraction level where it's easy to integrate into 
Qt, and I've also looked at options for doing the runtime dynamic 
linking dance (basically dlopen the backend library if available, fail 
gracefully with a nice error message if not available). It's more 
difficult for C++ and I think it won't be doable without some tedious 
scaffolding.
The core-core parts of Dferry have some pretty thorough tests. and it 
contains a graphical bus monitor that has some features that aren't 
available anywhere else.
Some other parts are more in a state where they work and maybe look 
pretty (that is very important to me), but don't do any error checking 
and maybe even use the default copy constructor even though some members 
are owning plain old pointers.
Also, its approach to structured data is pretty much like 
QDBusArgument's so that part is hopefully going to be really easy to 
port.

In any case, it can connect to the bus on Linux, and can send and 
receive messages. The marshaller should also be pretty fast as far as 
the spec allows. An obvious missing optimization is a fast path for 
simple arrays. But then, maybe DBus isn't really for builk data, you 
know?

And of course, I'm open to contributions. I expect a good understanding 
of low-level issues and a sense of style that leans towards simplicity 
and careful API design. No one needs another DBus library that is hard 
to comprehend both inside and outside.

Cheers,
Andreas