Axel Simon <axel.si...@ens.fr> writes:
> Hi Andy,
>
>
> On Dec 22, 2009, at 13:14, Andy Stewart wrote:
>
>> Hi Axel,
>>
>> Axel Simon <axel.si...@ens.fr> writes:
>>
>>> Hi Andy,
>>>
>>> sorry for not responding. I am not quite sure what the purpose of the
>>> functions below is and
>>> thus, I
>>> don't know how or even if they should be bound. They seem to be used to
>>> connect signals. So they
>>> either mirror functions that already exist. It would be good to understand
>>> the difference
>>> between
>>> these two sets of functions. Could you find out why these functions exist?
>> I think those three functions is *little problem*, just create
>> Closure.chs.pp file then compare function behaviour with C code.
>
> Sorry, I wasn't asking about how to bind the functions. I was asking what
> these functions are used
> for. Why are they necessary? Is the current functionality to attach signals
> not sufficient?
I'm newbie to DBus.
I can't explain why they're necessary, i just want to finish all
functions, don't missing anything, even i haven't understand them.
But i will look deeply about those un-binding functions.
>
>> The really problem is many necessary functions (such as
>> dbus_g_proxy_call) is "vararg method", and haven't equivalent
>> non-vararg functions to replace.
>
> It is possible to call these varargs functions if we do not supply any
> additional argumets and
> simply pass NULL as the vararg argument. Even though c2hs cannot
> automatically create the 'foreign
> import' declaration, it is possible to write it by hand.
Example below code:
------------------------------> code start <------------------------------
gboolean dbus_g_proxy_call (DBusGProxy *proxy,
const char *method,
GError **error,
GType first_arg_type,
...);
dbus_g_proxy_call (remote_object, "Add", &error,
G_TYPE_INT, 1, G_TYPE_INT, 2, G_TYPE_INVALID,
G_TYPE_INT, &sum, G_TYPE_INVALID)
------------------------------> code end <------------------------------
Like above example, it's call function `Add` and transform argument `1` and `2`
, and store result `3` in variable `sum`.
First three arguments of `dbus_g_proxy_call` is fixed, all arguments
that before first `G_TYPE_INVALID` is *function input argument*, after
first `G_TTYPE_INVALID` is *function output argument*.
So if we binding function `dbus_g_proxy_call`, we should declare like
this:
------------------------------> declare start <------------------------------
gProxyCall :: GProxy -> String -> (TypeableValue...) -> IO (TypeableValue, Bool)
------------------------------> declare end <------------------------------
TypeableValue is all type that GType allowed (such as: Int, String,
Bool...), in function `gProxyCall` we need do some transform, example,
we call
gProxyCall proxy "foo" (1, True)
inside of gProxyCall, it transform to
{#call dbus_g_proxy_call#} proxy "foo" error G_TYPE_INT 1 G_TYPE_BOOL True
G_TYPE_INVALID G_TYPE_INIT resultPtr G_TYPE_INVALID
`1` transform to `G_TYPE_INT 1`
`True` transform to `G_TYPE_BOOL True`
Then add `G_TYPE_INVALID` after input/ouput arguments.
Now the trouble is the input argument (TypeableValue...) number not fixed, it's
possible in Haskell?
>
>
>> So i can't write corresponding demo to test.
>>
>> For "vararg method", there's three solution to fix:
>>
>> 1-> Add C file in gtk2hs, in it have equivalent non-vararg functions,
>> those non-vararg function use *array* as function argument, then binding
>> those non-vararg functions.
>> But this is bad idea for gtk2hs, we should avoid to write other C functions.
>>
>> 2-> Patch to DBus-Glib, then wait next version release, then binding it,
>> and this solution perhaps slow.
>>
>> 3-> Use Haskell DBus implementation by "John Millikin",
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dbus-core
>> http://hackage.haskell.org/cgi-bin/hackage-scripts/package/dbus-client
>
> If a binding already exists, then it's obviously better to use that than to
> redo the work.
Yep, if DBus-Glib can work, we don't need use other DBus implementation.
But if "vararg method" problem can't fix, i only can choose John's
implementation.
Cheers,
-- Andy
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Gtk2hs-devel mailing list
Gtk2hs-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
