Axel Simon <axel.si...@in.tum.de> writes: > Andy, > > On May 9, 2010, at 14:27, Andy Stewart wrote: >> And this have another problem: >> >> Because every package just use subset signals of gtkmarshal.list, and >> it's endless that make `gtkmarshal.list` generate all signals. >> >> I recommend we add `fooMarshal.list` in every package that use >> siganls, >> and remove gtkmarshal.list from `callbackGen` directory. >> >> Example when `foo` package need new signal to add, just add >> something in `fooMarshal.list`, >> and don't change `gtk2hsBuildTools` package. >> >> Then `gtk2hsBuildTools` just for generate Siganls, and don't need >> manage >> signals list. >> > > Yes, that was the idea. The Signal generate does not actually allow > you to generate just a subset of signals, so you have to have a > marshall.list file for every package. > >> Another advantage is, every package just need generate Signals they're >> need, then package's install speed is much faster. > > Well, I'm pretty sure this is negligible. >>>> >>>> I think all code in Gtk.Signals should just depend on `glib` and >>>> not `gtk`, >>>> module `General.Threading` is same. >>> >>> While the threading functions are based on glib, the threading >>> library is initialized in >>> initGtk. Libraries that build on top of glib (like Pango and >>> Cairo) do not need to worry about >>> threading and do not need to use General.Threading. In fact, the >>> destructor in General.Threading >>> will free objects from the Gtk main loop which is never run in >>> applications not building on >>> Gtk. Thus, programs and libraries that only rely on glib, Pango >>> and Cairo may not use >>> General.Threading. Thus, I would prefer to leave this module in Gtk. >> Unfortunately, gio is exception, because GIO have connect_object_* >> signal, so it need function `objectUnrefFromMainloop` of `Threading`. >> Detail please see below link: > > > You don't need to import the Threading file since gio should not > create objects that are freed from the Gtk main loop. Otherwise gio > could not be used without gtk. > > You only need to remove the destructor specification from the cabal > file and the normal GObject destructor will be used to destroy gio > objects. I don't understand this, can you more detail?
I found Types.chs use `objectUnref` destroy object. But you have write fixed code `objectUnrefFromMainloop` in HookGenerator.hs, so `objectUnrefFromMainloop` always genrate in Signals.chs (connect_OBJECT__NONE), right? I have check gtk2hsHookGenerator, just three options: <moduleName> the module name for <outFile> <template-file> a path to the Signal.chs.template file <types-file> a path to a gtkmarshal.list file Any idea? -- Andy ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
