Re: [Gtk2hs-devel] darcs patch: Add WebKit binding r2

[Axel S. <Axe...@en...>]

On Wed, 2009-09-16 at 09:22 +0800, Cjacker wrote:
> 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?

You should copy and paste the original documentation and adjust it in
case it talks about C-specific stuff. I suppose the original functions
are documented, right?

If the original documentation refers to arguments by name, you can add
names by breaking down the line of the type as follows:

f :: A -> B -> C -> IO D

turns into

f ::
    A -- ^ @d@ the distance
 -> B -- ^ @obj@ the object
 -> C -- ^ @accel@ the acceleration
 -> IO D -- ^ the new object

Cheers,
Axel.

> or
> I just take other bindings as a reference?
> 
> 
> On Wed, Sep 16, 2009 at 5:16 AM, Axel Simon <Axe...@en...> 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.
> >
> >