Hi, Axel, Thanks for your reply.
Actually, I got a lot from your reply. I will try my best to add function comments according to webkitgtk's documents. Is there any guideline for comments style? or I just take other bindings as a reference? On Wed, Sep 16, 2009 at 5:16 AM, Axel Simon <axel.si...@ens.fr> wrote: > Hi Cjacker, > > On Sep 15, 2009, at 3:21, Cjacker Huang wrote: >> >> +-- a new webview instance should be created in your callback function >> +-- and connect a callback function to the signal "web-view-ready" of this >> instance >> +-- and finally return a (Ptr WebView) >> +-- You should not manipulate this instance util it emit "web-view-ready" >> signal! >> + >> +onCreateWebView :: (WebViewClass self) => self -> (WebFrame -> IO (Ptr >> WebView)) -> IO (ConnectId self) >> +onCreateWebView = >> + connect_OBJECT_STRING_PTR__BOOL "load-error" True >> + where connect_OBJECT_STRING_PTR__BOOL :: >> + (GObjectClass a', GObjectClass obj) => SignalName -> >> + ConnectAfter -> obj -> >> + (a' -> String -> GError-> IO Bool) -> >> + IO (ConnectId obj) >> + connect_OBJECT_STRING_PTR__BOOL signal after obj user = >> + connectGeneric signal after obj action >> + where action :: Ptr GObject -> Ptr GObject -> CString -> Ptr >> GError -> IO Bool >> + action _ obj1 str2 err1 = >> + peek err1 >>= \err1' -> >> + peekUTFString str2 >>= \str2' -> >> + makeNewGObject mkGObject (return obj1) >>= \obj1' >> -> >> + user (unsafeCastGObject obj1') str2' err1' >> + > > well, I've read your email about the signals and the segfaults but couldn't > quite get my head around it at the time. Two observations: > > If you need signal handlers like the ones above and they are not in > Signals.chs, then you can add them by modifying > tools/callbackGen/gtkmarshall.list. Please don't try to copy and paste > automatically generated code! > > Since your signal handler above must return a pointer to an object and our > tool can't do that, you have to return a (Ptr a). You already have the code > to extract a pointer from an encapsulated foreign pointer (WebView > (ForeignPtr WebView)): > >> +webViewToWebViewPtr :: WebView -> IO (Ptr WebView) >> +webViewToWebViewPtr webview = >> + withForeignPtr ((unWebView.toWebView) webview) $ >> + \webViewPtr -> return webViewPtr > > > However, the above code is bad, as it does something dangerous without it > being obvious. There's a function called unsafeForeignPtrToPtr which is > automatically in scope when you import Gtk2Hs' FFI module. The reason it's > called unsafe is that you could (a) create the WebView, (b) turn it into a > (Ptr WebView) using unsafeForeignPtrToPtr and (c) pass it back as the return > value. If the garbage collector runs just before (c), then there might be > nobody holding a reference to the ForeignPtr and the GC simply assumes the > newly created WebView is garbage. Thus, it's g_object_unref method is called > before webkit has a chance to increase the reference count. This might be a > reason for the segfault you saw, although it shouldn't occur regularly. The > Ptr can be safely passed back if you somehow manage to call touchForeignPtr > *after* you return it to C land. I'm not sure how to do that, quite frankly. > > I'd be happy to look into this problem if the rest of the binding is of high > quality. What I've just seen is that you lack a lot of comments. Comments > are crucial! Thus, if you could add a comment to each function, I'll sort > out the signal stuff. > > Cheers, > Axel. > > ------------------------------------------------------------------------------ Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
