Fix a crash in funcsig_hash
rgammon at real.com
Fri Jun 17 10:45:21 PDT 2005
Colin Walters wrote:
>>- My GInterface for in- and out-of-process media engines defines several
>>signals. AFAICS, I can't get dbus to automagically emit these signals,
>>so I have a bunch of dbus_g_proxy_connect_signal handlers that re-emit
>>signals on the GInterface using g_signal_emit_by_name
>That sounds like a bug. As a quick test, does the signal work if it's
>directly in the object class instead of an interface? We might need to
>iterate over the GInterfaces implemented by an object in addition to the
>object class itself; or it may be a bug in GLib.
I might be doing this totally wrong -- I used to have a HXDBusPlayer
that derived from DBusGProxy, and I created my signals with
dbus_g_proxy_add_signal. HXDBusPlayer implements a HXBasicPlayback
GInterface, HXBasicPlayback has a hx_basic_playback_get_video_area
method that returns a GtkWidget which gets packed into the ui.
I was thinking that doing a g_signal_connect to a signal defined with
dbus_g_proxy_add_signal might work, but it wasn't at the time.
I then moved the DBusGProxy into my HXDBusPlayer as a member, and
emitted the signals manually.
Is this the right idea?
>>The difficulty is that when I generate the glue for my dbus server, it's
>>set up such that the methods all return a bool and take their in/out
>>parameters in the function parameter list, whereas my GInterface has
>>many methods that return one out argument that is not a bool, and take
>>assorted in arguments.
>Do any of these functions return an error?
In general, I'm trying to use an asynchronous signal for errors. This
will kinda suck in terms of writing a player that deals well with
errors, but the general idea is to have something that can generically
wrap a number of engines, and different engines tend to report their
errors in different ways at different times.
I haven't figured out how I'm going to marshal that GError across yet...
I have this vague idea I should look at G_TYPE_BOXED.
>>Thus, I have a shim that goes from dbus calling conventions to my
>>GInterface api. Not a big deal, but I thought I'd bring it up in case
>>there's some annotation I can make to out parameters that would make
>>them show up as return values.
>Not yet, but it shouldn't be too hard to implement.
Cool, any idea what the xml syntax might look like?
>The org.gtk.objects thing was a bug, basically. Now fixed in the latest
>CVS. Can you give the latest CVS a try? You'll need to note in the XML
>now which signals are exported, and I changed the API for
>dbus_g_object_register_marshaller to be less painful to use.
Will check it out, thanks Colin.
rgammon at real.com
Developer for Helix Player
More information about the dbus