Fix a crash in funcsig_hash

[Ryan Gammon]

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.


-- 
Ryan Gammon
rgammon at real.com
Developer for Helix Player
https://player.helixcommunity.org