Hi Axel, Axel Simon <axel.si...@in.tum.de> writes:
> 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. Yes, i agree. 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. Another advantage is, every package just need generate Signals they're need, then package's install speed is much faster. Like principle of Type.chs in every package, just generate Type they need. > >> >> 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: https://patch-tag.com/r/AndyStewart/gio-branch/snapshot/current/content/pretty/System/GIO/Volumes/VolumeMonitor.chs https://patch-tag.com/r/AndyStewart/gio-branch/snapshot/current/content/pretty/System/GIO/Volumes/Drive.chs https://patch-tag.com/r/AndyStewart/gio-branch/snapshot/current/content/pretty/System/GIO/File/FileMonitor.chs If you keep Threading in `gtk` package, gio still need depend on gtk even gio generate Signals.chs itself, because Signals.chs file need import `Graphics.UI.Gtk.General.Threading` . And because glib, pango, cairo, don't need signal connect_*, so i suggest move Threading.chs (include hsgthread.h and hsgthread.c) to `gtk2hs/tools/callbackGen`. Make Signals.chs standalone with `gtk` package, then every package that use signal don't need depend `gtk` package. > >> 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. Yes, we need define gio flag in gtk.cabal. But we need fix Signals.chs problem before we add gio flag. > > 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. Yes, i want do it now. because my gio test code need some gio functions in `gtk`. And i want to reach a consensus on the details before i send new patch. Please let me know if you have better idea. Cheers, -- Andy ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
