From: Andy S. <laz...@gm...> - 2009-12-21 08:08:48
|
Andy Stewart <laz...@gm...> writes: > Hi Axel, > > I have finish DBus-Glib_0.80 > (http://dbus.freedesktop.org/releases/dbus-glib/dbus-glib-0.80.tar.gz) > binding for gtk2hs. > > Below is patch file: > > > I have finish all functions exception below three functions: > void dbus_g_object_register_marshaller_array > (GClosureMarshal marshaller, > GType rettype, > guint n_types, > const GType *types); > > void dbus_g_proxy_connect_signal (DBusGProxy *proxy, > const char *signal_name, > GCallback handler, > void *data, > GClosureNotify free_data_func); > > void dbus_g_proxy_disconnect_signal (DBusGProxy *proxy, > const char *signal_name, > GCallback handler, > void *data); > > Have no idea how to handle `GClosureMarshal` `GCallback` > `GClosureNotify`? After i search gnome documentation, i found above three Type implement in http://library.gnome.org/devel/gobject/unstable/gobject-Closures.html And i found just 'GClosure' and 'GClosureNotify' implement in 'glib/System/Glib/Signals.chs.pp' file, haven't 'GClosureMarshal' implementation. I think we should implement 'GClosureNotify', 'GClosureMarshal', 'GCallback' in file 'glib/System/Glib/Closure.chs.pp', and not 'glib/System/Glib/Signals.chs.pp', then we can fix above three functions in DBus-Glib. What do you think? -- Andy |
From: Axel S. <Axe...@en...> - 2009-12-22 08:19:42
|
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? Cheers, Axel. On Dec 21, 2009, at 9:01, Andy Stewart wrote: > Andy Stewart <laz...@gm...> writes: > >> Hi Axel, >> >> I have finish DBus-Glib_0.80 >> (http://dbus.freedesktop.org/releases/dbus-glib/dbus- >> glib-0.80.tar.gz) >> binding for gtk2hs. >> >> Below is patch file: >> >> >> I have finish all functions exception below three functions: >> void dbus_g_object_register_marshaller_array >> >> (GClosureMarshal marshaller, >> GType >> rettype, >> guint >> n_types, >> const >> GType *types); >> >> void dbus_g_proxy_connect_signal >> (DBusGProxy *proxy, >> const >> char *signal_name, >> GCallback >> handler, >> void *data, >> >> GClosureNotify free_data_func); >> >> void dbus_g_proxy_disconnect_signal >> (DBusGProxy *proxy, >> const >> char *signal_name, >> GCallback >> handler, >> void *data); >> >> Have no idea how to handle `GClosureMarshal` `GCallback` >> `GClosureNotify`? > After i search gnome documentation, i found above three Type > implement in > http://library.gnome.org/devel/gobject/unstable/gobject-Closures.html > > And i found just 'GClosure' and 'GClosureNotify' implement in > 'glib/System/Glib/Signals.chs.pp' file, haven't 'GClosureMarshal' > implementation. > > I think we should implement 'GClosureNotify', 'GClosureMarshal', > 'GCallback' in file 'glib/System/Glib/Closure.chs.pp', and not > 'glib/System/Glib/Signals.chs.pp', then we can fix above three > functions > in DBus-Glib. > > What do you think? > > -- 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 > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Andy S. <laz...@gm...> - 2009-12-22 13:42:25
|
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. 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. 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 For current situation, i want give up this patch, and try to use Haskell DBus implementation by "John Millikin", it's looks fully completely, even DBus-Glib have better integrate with Glib mainloop. I will finish rest work if have better solution for "vararg method" in DBus-Glib. It's worth to finish DBus-Glib binding when John have implement DBus protocol by Haskell? What do you think? -- Andy > > Cheers, > Axel. > > On Dec 21, 2009, at 9:01, Andy Stewart wrote: > >> Andy Stewart <laz...@gm...> writes: >> >>> Hi Axel, >>> >>> I have finish DBus-Glib_0.80 >>> (http://dbus.freedesktop.org/releases/dbus-glib/dbus- >>> glib-0.80.tar.gz) >>> binding for gtk2hs. >>> >>> Below is patch file: >>> >>> >>> I have finish all functions exception below three functions: >>> void dbus_g_object_register_marshaller_array >>> (GClosureMarshal marshaller, >>> GType rettype, >>> guint n_types, >>> const GType *types); >>> >>> void dbus_g_proxy_connect_signal (DBusGProxy *proxy, >>> const char *signal_name, >>> GCallback handler, >>> void *data, >>> GClosureNotify free_data_func); >>> >>> void dbus_g_proxy_disconnect_signal (DBusGProxy *proxy, >>> const char *signal_name, >>> GCallback handler, >>> void *data); >>> >>> Have no idea how to handle `GClosureMarshal` `GCallback` >>> `GClosureNotify`? >> After i search gnome documentation, i found above three Type implement in >> http://library.gnome.org/devel/gobject/unstable/gobject-Closures.html >> >> And i found just 'GClosure' and 'GClosureNotify' implement in >> 'glib/System/Glib/Signals.chs.pp' file, haven't 'GClosureMarshal' >> implementation. >> >> I think we should implement 'GClosureNotify', 'GClosureMarshal', >> 'GCallback' in file 'glib/System/Glib/Closure.chs.pp', and not >> 'glib/System/Glib/Signals.chs.pp', then we can fix above three functions >> in DBus-Glib. >> >> What do you think? >> >> -- 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 >> Gtk...@li... >> https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel |
From: Axel S. <Axe...@en...> - 2009-12-22 13:46:34
|
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? > 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. > 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. Cheers, Axel. |
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 |