Hi Andy, On May 9, 2010, at 11:18, Andy Stewart wrote:
> Axel, looks gnus have some problem that haven't send this mail. > > How do you think "split Gtk.Signals.chs from gtk package" ? > > I have push IconTheme patch, but still can't use > `iconThemeLookupByGicon`, that's need write `gio` in `build-depends` > of > gtk.cabal. > > But gio.cabal need Gtk.Signals, so i need write `gtk` in `build- > depends` > of gio.cabal. > > It's conflict between gio and gtk. I've been thinking about the signals. Having all signals in Glib is possible but maybe lead to problems later on: Suppose libFoo uses the signal connect functions from Gtk or Glib. If libFoo needs a new connectXXX function that is not yet provided the author can either ask for this signal handler to be added to Glib/Gtk or he/she can create his/her own Signal.chs file using a libFoo-specific marshall.txt file. The former option means that libFoo has to wait until a new version of Gtk/Glib comes out that contains the new signal handler. Thus, the second option is preferable. However, if later Gtk/Glib also needs the same connectXXX handler then connectXXX will be exported from the Signals.chs file of Gtk/Glib. Then compiling libFoo against this new Gtk/Glib version will break because there are two occurrences of connectXXX (even though they have the same implementation). Thus, the only dependable way seems to be that every package that uses signals defines and imports only its own Signals.chs file. As a consequence, we stop exporting Signals.chs from Gtk/Glib altogether. > > 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. > After split, not just gtk2hs-base project can use those Signals, any > project that need GObject-Signal can use those Signals. > > I have make GIO APIs works, but i don't know how to merge those > patches > if don't fix this problem. > > If you haven't time to do this, tell me your plan, i do it. In principle, it's ok for gtk to depend on gio. However, gio is only a dependency of gtk starting from version 2.XX, it's not required for Gtk + 2.8 and many other versions. Thus, we probably need to define a flag that says if gio is available or not. If you would like to add the flag and send me the patch for review, that would be appreciated. Otherwise I can do it possibly next weekend. Cheers, Axel ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
