From: Axel S. <A....@ke...> - 2004-06-21 19:57:21
|
Hi Duncan, I'm looking at streamlining the build process of gtk2hs a bit, possibly moving to automake. One question: You changed the Makefiles so that hierarchy.list is run through the C preprocessor. I don't quite remember why this was sensible since it is possible to conditionally include certain types with the "if" claus in hierarchy.list. If you can't come up with any other reason why hierarchy.list is run through CPP, I'd like to remove that and make e.g. a flag called SINCE2-4 which I can set when we have GTK 2.4 or higher. What do you think? Axel. |
From: Duncan C. <dun...@wo...> - 2004-06-21 20:49:12
|
On Mon, 2004-06-21 at 20:56, Axel Simon wrote: > I'm looking at streamlining the build process of gtk2hs a bit, possibly moving to > automake. One question: You changed the Makefiles so that hierarchy.list is run > through the C preprocessor. I don't quite remember why this was sensible since it is > possible to conditionally include certain types with the "if" claus in > hierarchy.list. If you can't come up with any other reason why hierarchy.list is run > through CPP, I'd like to remove that and make e.g. a flag called SINCE2-4 which I > can set when we have GTK 2.4 or higher. That seems fine. I did it the way I did so that we didn't need a new flag for each version of gtk+. So we can either make a new flag for each version or add a new syntax "gtk>=2.4". A new flag is probably sufficient. Speaking of build stuff. I'm not sure how the hierarchical libs affects the directory layout. Do I create a "Gnome" directory or do I need something like "Graphics/UI/Gnome". That's the way the ghc libs are laid out, eg: "libraries/template-haskell/Language/Haskell/TH/" Do we have a official/reserved place in the library namespace for gtk? Graphics.UI.Gtk perhaps? As for the gnome stuff, it's hard to know how to classify it. Much of it is non-gui (eg gconf). Duncan |
From: Axel S. <A....@ke...> - 2004-06-21 21:04:23
|
On Mon, Jun 21, 2004 at 09:48:51PM +0100, Duncan Coutts wrote: > On Mon, 2004-06-21 at 20:56, Axel Simon wrote: > > I'm looking at streamlining the build process of gtk2hs a bit, possibly moving to > > automake. One question: You changed the Makefiles so that hierarchy.list is run > > through the C preprocessor. I don't quite remember why this was sensible since it is > > possible to conditionally include certain types with the "if" claus in > > hierarchy.list. If you can't come up with any other reason why hierarchy.list is run > > through CPP, I'd like to remove that and make e.g. a flag called SINCE2-4 which I > > can set when we have GTK 2.4 or higher. > > That seems fine. I did it the way I did so that we didn't need a new > flag for each version of gtk+. So we can either make a new flag for each > version or add a new syntax "gtk>=2.4". A new flag is probably > sufficient. I'll use the flag approach then. It can't be that many... > > Speaking of build stuff. I'm not sure how the hierarchical libs affects > the directory layout. Do I create a "Gnome" directory or do I need > something like "Graphics/UI/Gnome". That's the way the ghc libs are laid > out, eg: "libraries/template-haskell/Language/Haskell/TH/" > > Do we have a official/reserved place in the library namespace for gtk? > Graphics.UI.Gtk perhaps? As for the gnome stuff, it's hard to know how > to classify it. Much of it is non-gui (eg gconf). We can just make something up. I personally don't like Graphics.UI since there are a lot of things that are not Graphics in user interfaces. Input for example. But to stick with the tradition, we can use Graphics.UI.Gtk, Graphics.UI.Gnome and Graphics.UI.Sourceview (or Graphics.UI.Gtk.Sourceview?). I don't think we can split the Gnome stuff into System.Gnome and Graphics.UI.Gnome unless we actually build two different packages (a package must have a unique top-level file). What do you think? Axel. |
From: Duncan C. <dun...@wo...> - 2004-06-21 21:27:44
|
On Mon, 2004-06-21 at 22:04, Axel Simon wrote: > On Mon, Jun 21, 2004 at 09:48:51PM +0100, Duncan Coutts wrote: > > Do we have a official/reserved place in the library namespace for gtk? > > Graphics.UI.Gtk perhaps? As for the gnome stuff, it's hard to know how > > to classify it. Much of it is non-gui (eg gconf). > > We can just make something up. I personally don't like Graphics.UI since there are a > lot of things that are not Graphics in user interfaces. Input for example. But to > stick with the tradition, we can use Graphics.UI.Gtk, Graphics.UI.Gnome and > Graphics.UI.Sourceview (or Graphics.UI.Gtk.Sourceview?). I don't think we can split > the Gnome stuff into System.Gnome and Graphics.UI.Gnome unless we actually build > two different packages (a package must have a unique top-level file). What do you > think? The wxHaskell folk seem to be using Graphics.UI.* so we should probably follow at least for the Gtk stuff (and related stuff like sourceview, I'd say Graphics.UI.Gtk.Sourceview). As for gnome packages, it might be worth asking for opinions on the libraries mailing list. Do you want to ask? It might be possible to split into System.Gnome and Graphics.UI.Gnome. The gnome people do this. They've got libgnome and libgnomeui, libbonobo and libbonoboui. Other gnome packages are mostly ui or non ui, eg glade is ui, gconf is non ui. I've been assuming that we build different packages for each gtk/gnome module and tie them together with a meta package that depends on all of them. So that would be ok with the restriction about a unique top-level file. Under a partitioned scheme it might look like: Graphics.UI.Gtk Graphics.UI.Gtk.Sourceview Graphics.UI.Gtk.Glade Graphics.UI.Gtk.Gnome --corresponds to libgnomeui Graphics.UI.Gtk.Gnome.Canvas Graphics.UI.Gtk.Gnome.Art --this'll probably be replaced with --Cairo before we get round to binding it Graphics.UI.Gtk.Gnome.Vte System.Gnome --corresponds to libgnome System.Gnome.GConf System.Gnome.Vfs System.Gnome.GStreamer Duncan |
From: Axel S. <A....@ke...> - 2004-06-21 22:59:40
|
On Mon, Jun 21, 2004 at 10:27:49PM +0100, Duncan Coutts wrote: > The wxHaskell folk seem to be using Graphics.UI.* so we should probably > follow at least for the Gtk stuff (and related stuff like sourceview, > I'd say Graphics.UI.Gtk.Sourceview). As for gnome packages, it might be > worth asking for opinions on the libraries mailing list. Do you want to > ask? Hm, I don't think people really care. I think we can just call our modules what we want. But if you want to ask, go ahead. > It might be possible to split into System.Gnome and Graphics.UI.Gnome. > The gnome people do this. They've got libgnome and libgnomeui, libbonobo > and libbonoboui. Other gnome packages are mostly ui or non ui, eg glade > is ui, gconf is non ui. > > I've been assuming that we build different packages for each gtk/gnome > module and tie them together with a meta package that depends on all of > them. So that would be ok with the restriction about a unique top-level > file. Ok. I'm not exactly sure how flexible automake is. If we want all the Haskell .chi files to go under <ghc-lib-dir>/gtk2hs then we might need to create (relative to the toplevel dir, i.e. gtk2hs-0.9.6): gtk2hs/Graphics/UI/Gtk/... ... gtk2hs/System/Gnome which isn't very nice, but clearly separates all files in this project from other projects. Alternatively, each module could go into its own subdir, i.e. gtk2hs/Graphics/UI/Gtk/... ... gnome-sys/System/Gnome > > Under a partitioned scheme it might look like: > Graphics.UI.Gtk > Graphics.UI.Gtk.Sourceview > Graphics.UI.Gtk.Glade I think from here on we should strip the "Gtk.", maybe even for Glade, too. > Graphics.UI.Gtk.Gnome --corresponds to libgnomeui > Graphics.UI.Gtk.Gnome.Canvas > Graphics.UI.Gtk.Gnome.Art --this'll probably be replaced with > --Cairo before we get round to binding it > Graphics.UI.Gtk.Gnome.Vte > > System.Gnome --corresponds to libgnome > System.Gnome.GConf > System.Gnome.Vfs > System.Gnome.GStreamer Let's split System and Graphics, then. Axel. |
From: Duncan C. <dun...@wo...> - 2004-06-22 00:19:51
|
On Mon, 2004-06-21 at 23:58, Axel Simon wrote: > On Mon, Jun 21, 2004 at 10:27:49PM +0100, Duncan Coutts wrote: > > As for gnome packages, it might be worth asking for opinions on the > > libraries mailing list. Do you want to ask? > > Hm, I don't think people really care. I think we can just call our modules what we > want. But if you want to ask, go ahead. Fair enough. I'll not bother then. > > I've been assuming that we build different packages for each gtk/gnome > > module and tie them together with a meta package that depends on all of > > them. So that would be ok with the restriction about a unique top-level > > file. > Ok. I'm not exactly sure how flexible automake is. If we want all the Haskell .chi > files to go under <ghc-lib-dir>/gtk2hs then we might need to create (relative to the > toplevel dir, i.e. gtk2hs-0.9.6): > gtk2hs/Graphics/UI/Gtk/... > ... > gtk2hs/System/Gnome This is how ghc's standard libraries's .hi files are laid out. > which isn't very nice, but clearly separates all files in this project from other > projects. Alternatively, each module could go into its own subdir, i.e. > gtk2hs/Graphics/UI/Gtk/... > ... > gnome-sys/System/Gnome I'm not sure it matters too much, whichever is easier and if they're equally easy, I'd pick the first option. > > > > Under a partitioned scheme it might look like: > > Graphics.UI.Gtk > > Graphics.UI.Gtk.Sourceview > > Graphics.UI.Gtk.Glade > I think from here on we should strip the "Gtk.", maybe even for Glade, too. So you mean: Graphics.UI.Gnome --extra gnome widgets Graphics.UI.Gnome.Canvas Graphics.UI.Gnome.Art Graphics.UI.Gnome.Vte > Let's split System and Graphics, then. Ok. So for the cvs/source directory layout, we'd use: gtk2hs/Graphics/UI/Gnome --actually this'd be empty at the moment --so we'd not create it just yet gtk2hs/System/Gnome I'm somewhat unsure about organising stuff when there are several files, eg my gconf stuff has three files GConf.hs, GConfValue.hs, and then generated files for signals and the class hierarchy. Do I put all these files in the top level directory or use a subdirectory and have a file that re-exports everything. Eg: gtk2hs/System/Gnome/GConf.hs --re-exports stuff gtk2hs/System/Gnome/GConf/GConf.hs --actual implementation gtk2hs/System/Gnome/GConf/* --various support files However we only want to expose gtk2hs/System/Gnome/GConf.hs(.hi) to the user. Everything else is private. Duncan |
From: Axel S. <A....@ke...> - 2004-06-22 08:36:20
|
On Tue, Jun 22, 2004 at 01:19:58AM +0100, Duncan Coutts wrote: > > > I've been assuming that we build different packages for each gtk/gnome > > > module and tie them together with a meta package that depends on all of > > > them. So that would be ok with the restriction about a unique top-level > > > file. > > Ok. I'm not exactly sure how flexible automake is. If we want all the Haskell .chi > > files to go under <ghc-lib-dir>/gtk2hs then we might need to create (relative to the > > toplevel dir, i.e. gtk2hs-0.9.6): > > gtk2hs/Graphics/UI/Gtk/... > > ... > > gtk2hs/System/Gnome > > This is how ghc's standard libraries's .hi files are laid out. > > > which isn't very nice, but clearly separates all files in this project from other > > projects. Alternatively, each module could go into its own subdir, i.e. > > gtk2hs/Graphics/UI/Gtk/... > > ... > > gnome-sys/System/Gnome > > I'm not sure it matters too much, whichever is easier and if they're > equally easy, I'd pick the first option. Ok. > > > Under a partitioned scheme it might look like: > > > Graphics.UI.Gtk > > > Graphics.UI.Gtk.Sourceview > > > Graphics.UI.Gtk.Glade > > I think from here on we should strip the "Gtk.", maybe even for Glade, too. > > So you mean: > > Graphics.UI.Gnome --extra gnome widgets > Graphics.UI.Gnome.Canvas > Graphics.UI.Gnome.Art > Graphics.UI.Gnome.Vte Yes. I don't know if Sourceview should be directly under UI or under UI.Gtk or maybe UI.Gtk.Extra. > So for the cvs/source directory layout, we'd use: > > gtk2hs/Graphics/UI/Gnome --actually this'd be empty at the moment > --so we'd not create it just yet > > gtk2hs/System/Gnome Well, it would have to be gtk2hs/ChangeLog gtk2hs/configure.ac gtk2hs/gtk2hs/Graphics/UI/Gnome because I can only install the whole subtree starting from (and including) the second gtk2hs directory name. > > I'm somewhat unsure about organising stuff when there are several files, > eg my gconf stuff has three files GConf.hs, GConfValue.hs, and then > generated files for signals and the class hierarchy. Do I put all these > files in the top level directory or use a subdirectory and have a file > that re-exports everything. Eg: > > gtk2hs/System/Gnome/GConf.hs --re-exports stuff > gtk2hs/System/Gnome/GConf/GConf.hs --actual implementation > gtk2hs/System/Gnome/GConf/* --various support files > Ghc can certainly cope with that. But I'm not sure automake can. What about renaming GConf/GConf.hs to something else, e.g. GConfImpl.hs or GConfPrivate.hs? > However we only want to expose gtk2hs/System/Gnome/GConf.hs(.hi) to the > user. Everything else is private. Shouldn't the user be able to import individual files? Besides, I'm not sure if you get away with just installing GConf.hi, it might refer to all the other .hi files. Axel. |
From: Matthew W. <ma...@al...> - 2004-06-22 09:11:31
|
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi guys. I've not been around much I know, but I've got some holiday coming up during which time I've made it a priority to fill in a few more missing widgets. I've got a project I want to write using gtk2hs and I'm probably going to need them. |>So you mean: |> |>Graphics.UI.Gnome --extra gnome widgets |>Graphics.UI.Gnome.Canvas |>Graphics.UI.Gnome.Art |>Graphics.UI.Gnome.Vte | | | Yes. I don't know if Sourceview should be directly under UI or under UI.Gtk or maybe | UI.Gtk.Extra. I'd guess UI.Gtk, as it's a Gtk component (albeit an add-on one). You could possibly get away with putting it under UI.Gnome as it's a GNOME Platform thing now, but since it doesn't require any GNOMEy stuff beyond GTK+ I'd guess UI.Gtk.Sourceview is best. |>However we only want to expose gtk2hs/System/Gnome/GConf.hs(.hi) to the |>user. Everything else is private. | | | Shouldn't the user be able to import individual files? Besides, I'm not sure if you | get away with just installing GConf.hi, it might refer to all the other .hi files. Not sure how this all works, but would the user ever *want* to import just a subset of GConf functionality? Is there a usable such subset? -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (Darwin) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFA1/e50UvYjCBpIlARArk/AKC5gpcPeCbn5ebR4gzvLArFoG6qFwCfdCOZ F023mnaCsvNDRJvNqLxavUA= =Ag6L -----END PGP SIGNATURE----- |
From: Axel S. <A....@ke...> - 2004-06-22 09:28:22
|
On Tue, Jun 22, 2004 at 10:11:21AM +0100, Matthew Walton wrote: > | Yes. I don't know if Sourceview should be directly under UI or under > UI.Gtk or maybe > | UI.Gtk.Extra. > > I'd guess UI.Gtk, as it's a Gtk component (albeit an add-on one). You > could possibly get away with putting it under UI.Gnome as it's a GNOME > Platform thing now, but since it doesn't require any GNOMEy stuff beyond > GTK+ I'd guess UI.Gtk.Sourceview is best. Although that suggests that Sourceview is somehow part of Gtk. Sourceview is going to be a separate GHC package, might not always be available and hence the user should be made aware that it is not part of Gtk. But maybe that's paranoid. > |>However we only want to expose gtk2hs/System/Gnome/GConf.hs(.hi) to the > |>user. Everything else is private. > | > | > | Shouldn't the user be able to import individual files? Besides, I'm > not sure if you > | get away with just installing GConf.hi, it might refer to all the > other .hi files. > > Not sure how this all works, but would the user ever *want* to import > just a subset of GConf functionality? Is there a usable such subset? I guess no usable subset, but if people like to explicitly only import what they need, then they could mention the submodules. If that is not possible, we might as well keep everything flat and not use the hierarchical modules. Axel. |
From: Duncan C. <dun...@wo...> - 2004-06-22 12:33:04
|
On Tue, 2004-06-22 at 10:28, Axel Simon wrote: > On Tue, Jun 22, 2004 at 10:11:21AM +0100, Matthew Walton wrote: > > I'd guess UI.Gtk, as it's a Gtk component (albeit an add-on one). You > > could possibly get away with putting it under UI.Gnome as it's a GNOME > > Platform thing now, but since it doesn't require any GNOMEy stuff beyond > > GTK+ I'd guess UI.Gtk.Sourceview is best. > > Although that suggests that Sourceview is somehow part of Gtk. Sourceview is going > to be a separate GHC package, might not always be available and hence the user > should be made aware that it is not part of Gtk. But maybe that's paranoid. I think it's ok to have packaging being mostly unrelated to location in the library namespace. I was reading the guidelines yesterday http://www.haskell.org/hierarchical-modules/libraries/layout.html (sec 3.1) and the principle is supposed to be grouping by functionality. It's not part of gtk, but even the C findings use the gtk namespace (or rather the gtk_ prefix). > > |>However we only want to expose gtk2hs/System/Gnome/GConf.hs(.hi) to the > > |>user. Everything else is private. > > | > > | > > | Shouldn't the user be able to import individual files? Besides, I'm > > not sure if you > > | get away with just installing GConf.hi, it might refer to all the > > other .hi files. No, you're right, I'm sure we can't. All the .hi files are needed. > > Not sure how this all works, but would the user ever *want* to import > > just a subset of GConf functionality? Is there a usable such subset? > > I guess no usable subset, but if people like to explicitly only import what they > need, then they could mention the submodules. If that is not possible, we might as > well keep everything flat and not use the hierarchical modules. No there is no usable subset. There are two modules that are separate only because they are automatically generated. Then I split the rest of the functionality into a main GConf module and another to deal with marshaling the 'GConfValue's that gconf uses. Noone would ever want to import any other than the main GConf module. I suppose it does no harm if users can import them directly, so long as the modules never appear in the generated documentation. Duncan |