[Interest] QtDBus interface design question

Roland Winklmeier roland.m.winklmeier at gmail.com
Thu Nov 7 19:01:57 CET 2013

Hey there,

I'm struggling with a design issue and cannot find a easy and clean
solution. So I hope you experts could help me out maybe.

I have a daemon application built with C++/Qt. It is a client for a
network and should run in the background. The plan was to connect the UI
via DBus to this daemon in order to make the objects inside the daemon
also available to other external tools/addons. So far nothing special,
this is done in many places in KDE.

The thing is , the object hierarchy is quite deep and complicated. The
best example is the object managing the applications settings, lets call
it CSettingsManager : public QObject. It holds several client QObjects,
representing each a different setting group:

|--- CServerSettings
|--- CUserSettings
|--- CLoggingSettings
|--- CGuiSettings

Now we want to expose these hierarchy via DBus. After reading thousands
of DBus applications and their interfaces, we decided to try the
following interface:


I think up to now its convenient. Instead of passing custom classes via
DBus, I thought its better to register the child objects too and just
point to the object via a QDbusObjectPath argument. So anyone can act
and react on the real object via DBus.
For example I can call CSettingsManager::getServerSettings() {return
QDBusObjectPath "/CSettingsManager/CServerSettings" } and create a
QDbusAbstractInterface with the returned objectpath and call methods on
the child object. So far so good. I have to mention here, the number of
CServerSettings is dynamic and decided during runtime (based on what is
specificed in the configuration file).
The DBus interface for example could look like:


The issue is now, I want to have a table view displaying the properties
for each Server and let the user edit it.

|Server 1 | IP address | port | name |
|Server 2 | IP address | port | name |
|Server 3 | IP address | port | name |

I could get a list of all objects and start retrieving their properties,
but lets suppose I have 1000 rows with 4 properties each = 4000 Dbus
calls to build the table. The performance would be horrible.

The only solution I can imagine is to pass the entire table in one DBus
message, but how. I cannot pass the objects itself, because I cannot
transfer an QObject via DBus. Creating plain structs and pass them is an
option but is rather dirty to me.

How are DBus experts handling this? I know our DBus interface is quite
complex and most others are far easier, but there must be a solution.
I'm still a DBus noob, so any hint how to change the design would be
very very welcome.

Thanks very much

More information about the Interest mailing list