Right now I'm creating a dbus binding, not unlike the glib one which encapsulate automatically complex types in dbus, with variants, dictionaries and everything.

Since i'm fiddling with the low-level dbus API, I don't always know if I'm doing the right thing when converting the messages for my higher-level API.

So I started to use dbus-monitor a lot, even in background to see if nothing was wrong in the messages. But dbus-monitor display either too much information (all messages for the session bus) or not enough (only the calls to the interface I'm choosing, and not the replies).

Then I started to use dbus-spy.py, but I modified the output to be able to have something like dbus-monitor and modified the filter rules too. So I got a tool allowing me to see all messages on a particular dbus interface, including replies and signals, and without all the other messages on the same bus. In addition, the output is colored so it's easier to follow.

On the other hand, I'm using d-feet and qdbusviewer to check that introspection is working fine (yes, I'm implementing org.freedesktop.DBus.Introspectable too). They interpret the XML and display it so it's easy and fast to understand if it's ok or not. In addition, d-feet and qdbusviewer allow to call the methods interactively, which is quite useful for quick tests to see if the methods and services are behaving well.

For more complex tests (for example, methods with complex parameters), I usually write python scripts (with just one method call, to the dbus module).

Apps/DFeet/WorkflowDesignD1 (last edited 2013-11-23 04:05:14 by WilliamJonMcCann)