From: Andy S. <laz...@gm...> - 2009-12-22 14:26:36
|
Axel Simon <Axe...@en...> writes: > Hi Andy, > > > On Dec 22, 2009, at 13:14, Andy Stewart wrote: > >> Hi Axel, >> >> Axel Simon <Axe...@en...> 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 |