From: John O. <joh...@gm...> - 2010-10-21 12:44:32
|
Good day everyone ! On Sun, Oct 10, 2010 at 12:50:43AM +0800, Andy Stewart wrote: > >From GObject hierarchy, there are many GObject not derive from > GInitiallyUnowned. > > Please keep patch small and just for one GObject per patch, then we can fix > if something wrong. At least, I've finished musing with the GObjects hierarchy and its C documentation. To summarize, I've "grep'ed" every occurrences of the functions "mkFoobar", where "Foobar is the name of an object not inheriting from GInitiallyUnowned, and fix the preceding {construct,make}NewGObject according to what I understand from the C documentation. … hopefully, this should cover most of (all?) the cases where GObjects are created. Patches are not really grouped by objects, but by filenames. The gio, pango and gtk libraries are affected. I've also rewritten the documentation for constructNewGObject to make it more coherent. If I have been too zealous in some part of the code by replacing traditional *NewObjects calls with "wrapNewGObject", you will quickly see some horribles glib warnings like the followings and occasionally some segfaults :) (process:###): GLib-GObject-WARNING **: invalid cast from `(null)' to `Foobar' (process:###): GLib-GIO-CRITICAL **: g_foo_bar_method: assertion `G_IS_FOO_BAR (foobar)' failed The good news is that in the opposite case where I forget to use "wrapNewGObject", you will not see any problems ,) Please test the modifications on real programs (if possible using pango and gio) and keep me informed if you see any strange things. regards, /John, Parsec3 + gtk source base + a Data.Map of ~10k string keys == an Haskell version of grep using only 500Mo of memory ^^ P.S.: I've attached an additional patch for gio/demo/FileManager.hs which did not compile on my machine. |