Where to start
h at realh.co.uk
Thu Mar 31 14:21:14 PST 2005
In <1112303114.26343.4.camel at localhost.localdomain>, Havoc Pennington wrote:
> On Thu, 2005-03-31 at 21:39 +0100, Tony Houghton wrote:
> > Oh, do I have to create/register an object and interface (and signal
> > name?) before referring to them in a message? I'll look into that.
> No, but they can be invalid. There are requirements on the format.
> That is object paths have to be /foo/bar/baz and interfaces have to be
> org.foo.Bar, roughly (see the spec for the complete requirements)
I think I got that right:
#define OPTSDBUS_NAME "net.sf.roxterm.Options"
#define OPTSDBUS_OBJECT_PATH "/net/sf/roxterm/Options"
#define OPTSDBUS_INTERFACE "net.sf.roxterm.Options"
#define OPTSDBUS_SIGNAL_NAME OPTSDBUS_NAME
I got a private message from someone who thought that signals couldn't
actually have arguments. Is that right? That would explain it. It would
mean I couldn't easily use signals to broadcast my config changes
> > So if the signals still don't work after I've fixed the first problem, I
> > should replace my call to gtk_main with a loop containing
> > gtk_main_iteration and check for dbus messages in the loop?
> No, I'm saying the main loop stuff is what _should_ work. The GProxy
> stuff is what probably doesn't work in 0.22.
Sorry, I didn't get how the receiving of messages was integrated into
the main loop if GProxy signals weren't working. But looking at
ROX-Session as an example I can now see that dbus has its own system of
callbacks (ROX-Session uses dbus_connection_register_object_path; I'd
probably need to use something slightly different for signal messages).
TH * http://www.realh.co.uk
More information about the dbus