Ken Brown<kbrown@cornell.edu> writes:
This is also a D-Bus client, which connects to the *same* session bus as
Emacs did due to $DBUS_SESSION_BUS_ADDRESS. Now you should see the
signal sent by dbus-monitor in Emacs.
OK, I started the session bus the right way this time, but I still
didn't see any signal from dbus-monitor in Emacs. I assume I should
have seen something in the echo area?
Yes. You could test whether both Emacs and dbus-monitor use the same bus
by reordering the calls:
- apply dbus-launch as described
- echo $DBUS_SESSION_BUS_ADDRESS
- in *another* shell, set $DBUS_SESSION_BUS_ADDRESS to this value, and
start dbus-monitor
- start Emacs in the first shell, and load dbus.el. You shall see in
the other shell output from dbus-monitor, telling that an application
has started. It will also tell you the name of that application, like
":1.2".
- apply (dbus-get-unique-name :session) in Emacs. The result shall be
the same name.
- start dbus-monitor in the same shell as Emacs. In the other
dbus-monitor, you should be notified, that an application has been started.
Maybe you can compile dbusbind.c with the compiler flag DBUS_DEBUG,
something like this in the Emacs source tree:
# MYCPPFLAGS='-DDBUS_DEBUG' make
This enables test traces sent to Emacs' stdout (the shell where you have
started it). I've introduced this flag while testing dbusbind.c, when it
has blocked Emacs, and I didn't want to start gdb ...
Maybe I can see something suspicious in the traces.
There's very little there. It prints the two lines
xd_add_watch: fd 8
xd_add_watch: fd 9
and no more. Does this tell you anything?
It's the initialization phase. Two watch functions are installed on file
descriptors 8 and 9 (connected to the system and session buses), polling
for incoming messages in Emacs' mainloop.
When you call dbus-get-unique-name, there shall be more output. But this
works, as you have confirmed, so this is not the interesting case.
I've hoped to see more :-( Did you play with the running/non-running
system bus?