Suggestions for a Windows D-Bus client development environment

Schmottlach, Glenn glenn.schmottlach at
Thu Apr 16 10:55:53 PDT 2009

I'd like to make a correction to my assertion that the existing
NDesk-DBus is not being maintained. On the contrary, the development
branch is being actively updated (sorry Alp). So if you're interested in
seeing what's cooking on the bleeding edge, please download from the GIT
repository. I'm looking at this now and Alp (the maintainer) has been
kind enough to provide me with some help.




From: dbus-bounces at
[mailto:dbus-bounces at] On Behalf Of Schmottlach,
Sent: Wednesday, April 15, 2009 9:32 AM
To: dbus at
Subject: Suggestions for a Windows D-Bus client development environment


I would like to create an environment (under Windows) that would allow
me to develop graphical D-Bus client applications that talk via TCP/IP
to an embedded target platform running several custom D-Bus services. My
problem isn't related to running the daemon on the target or enabling
remote access over TCP/IP (I've already done that), it's finding a
suitable language binding and graphical framework for rapidly creating
graphical D-Bus test applications to test these remote services.


What I'd *like* to use is Python (or another Python-like scripting
language) that has a suitable D-Bus binding that can be built (and run)
on a PC running Windows (my host platform). I know this is a slam-dunk
if I'm running Linux. I'd pick the standard python-dbus binding (which
used Glib) and use the python-gtk module to do my GUI. Unfortunately,
other than a pre-compiled python-dbus binding (with the necessary
Python/C bindings) someone managed to compile for an older version of
Python (on Windows), there is no native Windows solution. The problem
isn't building a native D-Bus reference library for Windows (that's
straightforward), it's compiling python-dbus (and its dependencies -
like glib/gtk) on a Windows platform. I made several attempts at this
and never arrived at a workable (or easy) solution.


I next tried building the NDesk-DBus .NET binding for Windows. Again, it
appears this was originally intended to be built under Linux using Mono
but I managed to hack the build environment to build it under Windows.
The end result was a .NET assembly under Windows. I next installed
IronPython and GTK# (the .NET port of GTK) and actually got an
application up and running under Windows. Unfortunately, I cannot figure
out how to receive signals using NDesk-DBus/IronPython and it only
appears to support synchronous messaging and only a single return
parameter. Also, it requires me to define D-Bus proxy interfaces using
C# (and compile them into assemblies/DLLs) that mirror the D-Bus
services I'd like to call. Finally, it doesn't appear this project is
being maintained or updated since ~2006. So, without examples (none
which I could find for a NDesk/IronPython combination), this approach
appeared to be a dead-end.


So, that leaves me looking at the D-Bus Java binding and potentially
leveraging Jython for the glue and Swing for the GUI. Again, the Java
binding appears to be geared to be built under Linux. I attempted to
build it under Windows and at least got the associated .jar dependencies
built (of course it failed building the JNI stubs for Unix local
(domain) sockets).  Has anyone had any luck using the Jython/D-Bus Java
combination on Windows? Can anyone provide any sample code where it is


In a nutshell, I am looking for suggestions from D-Bus developers.
Ideally, I want a rapid prototyping environment under Windows that would
allow me to quickly put together graphical test applications using a
dynamic scripting language. Can anyone offer a suitable combination, a
success story, or point me at sample code? Again, this is easy under
Linux but unfortunately, not an option for me at this time since my
developers use a corporate (Windows) host platform most of the time. I
guess there is always VmWare/Linux on Windows, but I'd like to try to
avoid that.


Thanks . . .

-------------- next part --------------
An HTML attachment was scrubbed...

More information about the dbus mailing list