Hi John, On 23.09.2010, at 01:26, John Obbele wrote: > channelGetProperty :: XfconfChannelClass self > => self -> String -> IO (Maybe XfconfValue) > channelGetProperty chan property = > withXfconf chan $ \chanPtr -> > withUTFString property $ \prop -> > allocaGValue $ \gvalue@(GValue gPtr) -> do > -- c_get_property == FFI call to xfconf_channel_get_property > success <- c_get_property chanPtr prop gPtr > case fromGBoolean success of > False -> do -- FIXME: bug in glib GValue implementation ? > -- gvalue was not initialize by c_get_property > -- allocaGValue will try to unset it > -- and throw an error if our gvalue stay as it is > valueInit gvalue bool > return Nothing > True -> Just `fmap` toXfconfValue gvalue > """ > > As said in the haskell comment, when xfconf_channel_get_property > cannot find the property (the key in the xfconf "hash" table), it > returns False and doesn't set anything inside our GValue, which > trigger this glib error message: > > """ > (process:20219): GLib-GObject-CRITICAL **: g_value_unset: assertion > `G_IS_VALUE (value)' failed > """ > > A simple work-around is to arbitrary valueInit'ed our gvalue to > something (bool in the previous code example) before ending our > haskell function (and letting allocaGValue clean the memory). >
Yes, the problem is that allocaGValue will expect the functions that is called to set the GValue because it will tear down the GValue afterwards. > Note that if I valueInit' the gvalue before the call to xfconf, I > am getting an error saying Glib cannot initialized the gvalue > since it already was. (grrr) > > ... consequently, I propose to patch glib/System/Glib/GValue.chs > (or add a message in haddock warning against this edge case): > Why can't you simply initialize the GValue *only* in the error case? We could patch GValue but that means that your library will be dependent on some future version of gtk. > [!pseudo-patch attached!] > >>> Then, concerning the question. I would like to cast >>> XfconfChannel to a GObject, play with its attribute and connect >>> to it some signals. If I've correctly understood the recent >>> cabalization of gtk2hs and its addons, and based on gconf-0.11, I >>> should hook Setup.hs to Gtk2HsSetup.hs, create two files, >>> "marshal.list" and "hierarchy.list" and modify the .cabal >>> configuration accordingly, am I right ? >>> >> >> Yes. You need marshal.list if you have callbacks, otherwise you >> don't have to bother. You probably need hierarchy.list since that is >> required if you want the tools to create new class definitions. > > I have successfully cast my object to the GObjectClass by copy-pasting > samples of code I have found. Same for signals, they are working > fine. ... except that I'm using plain vanilla c2hs with > pre-compiled gtk2hs-0.10 packages :( > This is bad. Signals.chs and Types.chs must be automatically generated. I'm not sure how well the standard c2hs could work, but at least dependencies are broken so that a project with several files will not work. You will run into problems that certain pointers to and from C functions are recognizes as the Haskell types they were declared as, I think. > I don't know if it really worths it now to try hooking my lib with > the Gtk2hsSetup.hs. Sorry but until I get a new fedora 14 system > (with shiny new gtk2hs-0.11 packages courtesy of J.Petersen), I > will stick with my simple hand-coded Signals.chs and Types.chs. > You certainly do not want to build a package on something pre 0.11(.1). >>> What if my reference to the XfconfChannel gobject is a "weak" >>> reference ? Is there some special things to do, since I do not >>> require a g_object_unref finalizer. >> >> At the moment, a Haskell handle to an object is a strong reference. >> If it goes out of scope, then the reference counter of that object >> is decremented. This scheme is a bit problematic since you can >> create space leaks by creating closures that include these object >> references and then attach these closures to callbacks from the same >> object. We have not yet figured out a way to circumvent this >> problem. The only way to get rid of an object is to explicitly >> destroy it. > > I have tried to solve my weak-reference problem by artificially > increasing the object reference with objectRef. If I've correctly > read the glib documentation, this should do the trick. > I don't follow. What problem do you want to solve? Do you have weak references anywhere? Cheers, Axel ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
