Andy Stewart <lazycat.mana...@gmail.com> writes: > 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. Because every package's Signals.chs is standalone, so won't have "signal conflict* problem.
For test which signals that package need, we can generate empty Signals.chs file first and compile package, then use grep catch signals from compile error. Cheers, -- Andy ------------------------------------------------------------------------------ _______________________________________________ Gtk2hs-devel mailing list Gtk2hs-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/gtk2hs-devel
