From: Colin M. <m....@go...> - 2009-05-13 15:11:33
|
"on win styleSet (return ())" will fail because the style-set signal is passed NULL. I've changed it to take Maybe, but this does raise the point that callback parameters should be documented so we can grep for NULLs. In-line documentation would be nice but it tends to run off the page and I'm not sure how Haddock will treat it: styleSet :: WidgetClass self => Signal self (Maybe Style --^ docs go here? -> IO ()) Any ideas? I also implemented styleGetFontDescription but ran into a problem with mutually recursive modules. G.U.G.Pango.FontDescription depends on G.U.G.General.Structs, so unless gtk2hs uses GHC hs-boot files, Structs cannot depend on FontDescription. I wrote a program to look at cyclic dependencies in the GTK+ headers. The Structs-FontDescription cycle does not exist in the headers, but there are other cycles. My solution for now is to move the Style-specific hsc into a separate module, StyleStruct.hsc. |
From: Colin M. <m....@go...> - 2009-05-13 15:27:59
|
On second thoughts, perhaps the best approach is the split Gdk.Structs into Gtk.Structs and Gtk.Gdk.Structs? The cycle I hit is GtkStyle->PangoFontDescription->GdkColor, which is a cycle between (Gtk+Gdk) and Pango. |
From: Axel S. <Axe...@en...> - 2009-05-14 07:38:58
|
Hi Colin, On Wed, 2009-05-13 at 16:27 +0100, Colin McQuillan wrote: > On second thoughts, perhaps the best approach is the split Gdk.Structs > into Gtk.Structs and Gtk.Gdk.Structs? The cycle I hit is > GtkStyle->PangoFontDescription->GdkColor, which is a cycle between > (Gtk+Gdk) and Pango. thanks for the patches. I'll apply them as soon as I get around to it. Splitting Structs into two files, one for Gdk and one for Gtk would mirror what is done with Enums. However, the distinction of Gdk.Enums and Gtk.Enums is done already in the C libraries whereas the split of Structs would be a pure Gtk2Hs decision. Thus, I wonder, if this will really help us. Maybe the right thing is to create many more .hsc files whenever they're needed. For instance, we could have one for FontDescription or, as you've done, we could just have an hsc file for Styles. I'm not sure what is best here. It's not terribly important what we do, since these modules are invisible to the user. Just some musings. We could do the split of structs into Gdk and Gtk and see if it helps. Axel. |
From: Colin M. <m....@go...> - 2009-05-14 10:46:00
Attachments:
split-gdk-structs.dpatch
|
2009/5/14 Axel Simon <Axe...@en...>: > Hi Colin, > > On Wed, 2009-05-13 at 16:27 +0100, Colin McQuillan wrote: >> On second thoughts, perhaps the best approach is the split Gdk.Structs >> into Gtk.Structs and Gtk.Gdk.Structs? The cycle I hit is >> GtkStyle->PangoFontDescription->GdkColor, which is a cycle between >> (Gtk+Gdk) and Pango. > > thanks for the patches. I'll apply them as soon as I get around to it. > > Splitting Structs into two files, one for Gdk and one for Gtk would > mirror what is done with Enums. However, the distinction of Gdk.Enums > and Gtk.Enums is done already in the C libraries whereas the split of > Structs would be a pure Gtk2Hs decision. Thus, I wonder, if this will > really help us. Maybe the right thing is to create many more .hsc files > whenever they're needed. For instance, we could have one for > FontDescription or, as you've done, we could just have an hsc file for > Styles. I'm not sure what is best here. It's not terribly important what > we do, since these modules are invisible to the user. > > Just some musings. We could do the split of structs into Gdk and Gtk and > see if it helps. > > Axel. > I don't see what the relevant difference is between Structs and Enums. This does mirror the C libraries, since Gtk and Gdk are separate libraries. However, merging Gtk and Gdk really shouldn't cause cycles since the C dependency graph is: gtk+-2.0 -> gdk-2.0 -> pango The cycles are caused by gtk2hs Pango bindings using Gdk types. Why is Gdk.Rectangle used in some places in Pango rather than PangoRectangle? Is this to avoid the trouble of explicit conversion? It does affect users that our Pango bindings can never be divorced from Gdk, though it's a minor issue. So I'm not sure what the real problem is. For now I've split off Gdk.Structs since this is quite easy an easy split to make. Thu May 14 11:27:36 BST 2009 m....@gm... * Split off G.U.G.Gdk.Structs from G.U.G.General.Structs PS. Could the gtk2hs trac be set to send mail to gtk2hs-devel? I created a ticket I'd like opinions on: http://hackage.haskell.org/trac/gtk2hs/ticket/1167 |