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 _______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
