From: Duncan C. <dun...@wo...> - 2006-11-25 20:55:16
|
Hia folks, Several months ago we had a longish thread here about writing a tutorial. We discussed tools etc and came to some conclusions on that topic. What didn't happen however was any actual writing! :-) So that now that we do have the technology I'd like to ask again for help writing an intro tutorial (or indeed tutorials on any more advanced aspect of build GUI apps with Gtk2Hs). Thanks to Hans van Thiel porting a Glade tutorial from C to Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to approval from Hans and the original author, that tutorial will be hosted on the Gtk2Hs site. So here's the setup: We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via latex) output. We also have a post-processor program that does syntax highlighting of Haskell code and adds hyperlinks to the haddock documentation. Here's an example. It's just a skeleton of a tutorial, but you get the idea: http://haskell.org/gtk2hs/docs/tutorial/intro/ And the source: http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t So how can you help? Get the Gtk2Hs sources and write something! :-) The easiest way for us to receive contributions is via darcs send, just like ordinary code contributions. There's no need for contributions to be major works, just adding a bit here or there or editing/fixing existing stuff is great. If you don't want to use darcs then just email gtk...@li... with your changes. Details: * Get the Gtk2Hs sources with darcs: darcs get --partial http://darcs.haskell.org/gtk2hs/ * install txt2tags: http://txt2tags.sourceforge.net/download.html * Workflow: 1. cd gtk2hs/docs/tutorial/intro/ 2. $EDITOR intro.t2t 3. make 4. { repeat steps 2-3 until satisfied } 5. darcs record 6. darcs send If you have particular ideas about how a tutorial should be structured I'd be glad to hear them. Any questions or other suggestions? Duncan |
From: Neil M. <ndm...@gm...> - 2006-11-25 21:08:24
|
Hi > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > Get the Gtk2Hs sources and write something! :-) > The easiest way for us to receive contributions is via darcs send, just I can think of one way to get more contributions, put it on the wiki! Is there any good reason for this not to be on the wiki, where everyone can edit/improve it? Thanks Neil |
From: Duncan C. <dun...@wo...> - 2006-11-25 22:06:41
|
On Sat, 2006-11-25 at 21:08 +0000, Neil Mitchell wrote: > Hi > > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > Get the Gtk2Hs sources and write something! :-) > > The easiest way for us to receive contributions is via darcs send, just > > I can think of one way to get more contributions, put it on the wiki! > Is there any good reason for this not to be on the wiki, where > everyone can edit/improve it? Heh, I was waiting for someone to say this :-) Actually it has been on the haskell.org wiki for months with no changes. A wiki doesn't magically attract contributers. Our source code isn't in a wiki and people seem to be able to use darcs send ok. So there are a few reasons I guess: * a format that we can use for offline as well as online docs. (txt2tags can generate latex & (x)html, we can use html templates + css to customise the look.) * editorial control. The original author of the glade tutorial wasn't too happy with derivatives of his work being in a wiki format. We must respect that (of course that's only on tutorial). To some extent the same issue applies to an intro tutorial (though not to the other tutorials). An intro tutorial is an important document and needs an editorial eye occasionally. * more flexibility with tools: we now have tools that automatically markup Haskell code snippets and hyperlink them to the haddock docs. We can't do that on a wiki (at least not easily). * integration with the rest of the Gtk2Hs website: we use a template to make it fit in. http://haskell.org/gtk2hs/docs/tutorial/intro/ If people want to do stuff in a wiki anyway, then by all means. We can accept contributions that way: http://haskell.org/haskellwiki/Gtk2Hs/Tutorials/Intro However I don't think the problem is technical barriers to entry. I think the issue is just that we need to make people aware that we are seeking help in this area, that they can help and that it's not difficult to contribute. Duncan |
From: Hans v. T. <hth...@zo...> - 2006-11-27 14:30:17
|
Hello All, The tutorial outline looks good to me, and I'd be happy to contribute. However, since I'm not a subject matter expert, I'd need some pointers to basic texts. Maybe just about GTK+, in those cases where Gth2Hs usage is a port of the same principle. The problem here seems to be, that those who know don't like to write, and those who'd like to write don't know (in my case anyway :-)). But with some good starting points, and some assured feed back (quality control), it seems feasible. I also think there are some good Gtk2hs examples available, and imo we should use these whenever possible. Best Regards, Hans van Thiel On Sat, 2006-11-25 at 20:55 +0000, Duncan Coutts wrote: > Hia folks, > > Several months ago we had a longish thread here about writing a > tutorial. We discussed tools etc and came to some conclusions on that > topic. What didn't happen however was any actual writing! :-) > > So that now that we do have the technology I'd like to ask again for > help writing an intro tutorial (or indeed tutorials on any more advanced > aspect of build GUI apps with Gtk2Hs). > > Thanks to Hans van Thiel porting a Glade tutorial from C to > Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to > approval from Hans and the original author, that tutorial will be hosted > on the Gtk2Hs site. > > So here's the setup: > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via > latex) output. We also have a post-processor program that does syntax > highlighting of Haskell code and adds hyperlinks to the haddock > documentation. > > Here's an example. It's just a skeleton of a tutorial, but you get the > idea: > http://haskell.org/gtk2hs/docs/tutorial/intro/ > > And the source: > http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t > > > So how can you help? > > Get the Gtk2Hs sources and write something! :-) > > The easiest way for us to receive contributions is via darcs send, just > like ordinary code contributions. There's no need for contributions to > be major works, just adding a bit here or there or editing/fixing > existing stuff is great. > > If you don't want to use darcs then just email > gtk...@li... with your changes. > > Details: > > * Get the Gtk2Hs sources with darcs: > darcs get --partial http://darcs.haskell.org/gtk2hs/ > > * install txt2tags: http://txt2tags.sourceforge.net/download.html > > * Workflow: > 1. cd gtk2hs/docs/tutorial/intro/ > 2. $EDITOR intro.t2t > 3. make > 4. { repeat steps 2-3 until satisfied } > 5. darcs record > 6. darcs send > > > If you have particular ideas about how a tutorial should be structured > I'd be glad to hear them. > > Any questions or other suggestions? > > Duncan > |
From: Gour <li...@at...> - 2006-11-27 17:51:14
|
On Mon, 2006-11-27 at 15:32 +0100, Hans van Thiel wrote: > The problem here seems to be, that those who know don't like to write, > and those who'd like to write don't know (in my case anyway :-)).=20 True. Catch 22 :-( I promised to write something, but, so far, didn't have time to play with gtk2hs to learn enough for writing a tutorial. > But with some good starting points, and some assured feed back (quality > control), it seems feasible. Sure. >=20 > I also think there are some good Gtk2hs examples available, and imo we > should use these whenever possible.=20 Right. I'd say that eg. Python & Ruby tutorials are pretty good. At the moment I am swayed by some video-editing projects and deadlines are quickly approaching, but after that I hope to resume helping gtk2hs project according to my skills. Sincerely, Gour |
From: Axel S. <A....@ke...> - 2006-11-27 14:59:00
|
Hans (and everyone who'd like to contribute), On Mon, 2006-11-27 at 15:32 +0100, Hans van Thiel wrote: > Hello All, > > The tutorial outline looks good to me, and I'd be happy to contribute. > However, since I'm not a subject matter expert, I'd need some pointers > to basic texts. Maybe just about GTK+, in those cases where Gth2Hs usage > is a port of the same principle. The problem here seems to be, that > those who know don't like to write, and those who'd like to write don't > know (in my case anyway :-)). But with some good starting points, and > some assured feed back (quality control), it seems feasible. We could, in principle, translate the Gtk+ tutorial: http://www.gtk.org/tutorial/ However, it is quite big and might, in fact, be too much to translate completely. Furthermore, there are many sections which seem rather obvious and thereby obfuscate the differences between Gtk and other GUI toolkits. For Gtk2Hs we might want to try to write about specific subjects which are particularly challenging or unusual, for instance: - basics (widgets, type hierarchy, casting, common type errors) - the main event loop - packing widgets (Gtk2Hs uses a single constructor for specifying how a widget should expand whereas Gtk+ uses two boolean flags) - signals (we will soon revamp the way signals are bound, so this topic has to wait a bit) - creating your own widget with DrawingArea and Cairo - TreeView widget (very complex, hence requires documentation) - TextView widget (as above) Things that are not quite mature in Gtk2Hs and which we should probably document later: - key binings - menu system (maybe we can do better than Gtk here) Writing about any of these topics can be guided by the tutorial, trial and error and by the examples. It would be great if we could get a hands-on tutorial which provides a file with some basic infrastructure which can be loaded into ghci where the user can then copy and paste the examples from the tutorial. For instance, I posted a small file which allowed to use Cairo from within ghci. If people think it's a good idea, we could post bulletin points above on the web-page so that people know what they can start on. I started on documenting the (new) TreeView widget (which I will check into darcs), but none of the other topics has received any documentation. Hope this helps. Let us know what you think! Axel. > I also think there are some good Gtk2hs examples available, and imo we > should use these whenever possible. > > On Sat, 2006-11-25 at 20:55 +0000, Duncan Coutts wrote: > > Hia folks, > > > > Several months ago we had a longish thread here about writing a > > tutorial. We discussed tools etc and came to some conclusions on that > > topic. What didn't happen however was any actual writing! :-) > > > > So that now that we do have the technology I'd like to ask again for > > help writing an intro tutorial (or indeed tutorials on any more advanced > > aspect of build GUI apps with Gtk2Hs). > > > > Thanks to Hans van Thiel porting a Glade tutorial from C to > > Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to > > approval from Hans and the original author, that tutorial will be hosted > > on the Gtk2Hs site. > > > > So here's the setup: > > > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > > > We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via > > latex) output. We also have a post-processor program that does syntax > > highlighting of Haskell code and adds hyperlinks to the haddock > > documentation. > > > > Here's an example. It's just a skeleton of a tutorial, but you get the > > idea: > > http://haskell.org/gtk2hs/docs/tutorial/intro/ > > > > And the source: > > http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t > > > > > > So how can you help? > > > > Get the Gtk2Hs sources and write something! :-) > > > > The easiest way for us to receive contributions is via darcs send, just > > like ordinary code contributions. There's no need for contributions to > > be major works, just adding a bit here or there or editing/fixing > > existing stuff is great. > > > > If you don't want to use darcs then just email > > gtk...@li... with your changes. > > > > Details: > > > > * Get the Gtk2Hs sources with darcs: > > darcs get --partial http://darcs.haskell.org/gtk2hs/ > > > > * install txt2tags: http://txt2tags.sourceforge.net/download.html > > > > * Workflow: > > 1. cd gtk2hs/docs/tutorial/intro/ > > 2. $EDITOR intro.t2t > > 3. make > > 4. { repeat steps 2-3 until satisfied } > > 5. darcs record > > 6. darcs send > > > > > > If you have particular ideas about how a tutorial should be structured > > I'd be glad to hear them. > > > > Any questions or other suggestions? > > > > Duncan > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Hans v. T. <hth...@zo...> - 2006-11-27 19:07:43
|
Hello Axel, This looks interesting. I'll have a more detailed look and, depending on any other reactions and comments, I think I could maybe do - basics (widgets, type hierarchy, casting, common type errors) and fit it into the tutorial outline. Once more about the available examples (calculator a.o.), which are even included in the FC5 Gtk2Hs documentation package (I don't know about fc6 yet). They are well documented, only not for the beginner, and imo it would be a pity not to use one or more of them in a tutorial. Regards, Hans On Mon, 2006-11-27 at 14:58 +0000, Axel Simon wrote: > Hans (and everyone who'd like to contribute), > > On Mon, 2006-11-27 at 15:32 +0100, Hans van Thiel wrote: > > Hello All, > > > > The tutorial outline looks good to me, and I'd be happy to contribute. > > However, since I'm not a subject matter expert, I'd need some pointers > > to basic texts. Maybe just about GTK+, in those cases where Gth2Hs usage > > is a port of the same principle. The problem here seems to be, that > > those who know don't like to write, and those who'd like to write don't > > know (in my case anyway :-)). But with some good starting points, and > > some assured feed back (quality control), it seems feasible. > > We could, in principle, translate the Gtk+ tutorial: > > http://www.gtk.org/tutorial/ > > However, it is quite big and might, in fact, be too much to translate > completely. Furthermore, there are many sections which seem rather > obvious and thereby obfuscate the differences between Gtk and other GUI > toolkits. For Gtk2Hs we might want to try to write about specific > subjects which are particularly challenging or unusual, for instance: > > - basics (widgets, type hierarchy, casting, common type errors) > - the main event loop > - packing widgets > (Gtk2Hs uses a single constructor for specifying how a widget should > expand whereas Gtk+ uses two boolean flags) > - signals > (we will soon revamp the way signals are bound, so this topic has to > wait a bit) > - creating your own widget with DrawingArea and Cairo > - TreeView widget (very complex, hence requires documentation) > - TextView widget (as above) > Things that are not quite mature in Gtk2Hs and which we should probably > document later: > - key binings > - menu system (maybe we can do better than Gtk here) > > Writing about any of these topics can be guided by the tutorial, trial > and error and by the examples. It would be great if we could get a > hands-on tutorial which provides a file with some basic infrastructure > which can be loaded into ghci where the user can then copy and paste the > examples from the tutorial. For instance, I posted a small file which > allowed to use Cairo from within ghci. > > If people think it's a good idea, we could post bulletin points above on > the web-page so that people know what they can start on. I started on > documenting the (new) TreeView widget (which I will check into darcs), > but none of the other topics has received any documentation. > > Hope this helps. Let us know what you think! > Axel. > > > > > I also think there are some good Gtk2hs examples available, and imo we > > should use these whenever possible. > > > > > > > On Sat, 2006-11-25 at 20:55 +0000, Duncan Coutts wrote: > > > Hia folks, > > > > > > Several months ago we had a longish thread here about writing a > > > tutorial. We discussed tools etc and came to some conclusions on that > > > topic. What didn't happen however was any actual writing! :-) > > > > > > So that now that we do have the technology I'd like to ask again for > > > help writing an intro tutorial (or indeed tutorials on any more advanced > > > aspect of build GUI apps with Gtk2Hs). > > > > > > Thanks to Hans van Thiel porting a Glade tutorial from C to > > > Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to > > > approval from Hans and the original author, that tutorial will be hosted > > > on the Gtk2Hs site. > > > > > > So here's the setup: > > > > > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > > > > > We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via > > > latex) output. We also have a post-processor program that does syntax > > > highlighting of Haskell code and adds hyperlinks to the haddock > > > documentation. > > > > > > Here's an example. It's just a skeleton of a tutorial, but you get the > > > idea: > > > http://haskell.org/gtk2hs/docs/tutorial/intro/ > > > > > > And the source: > > > http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t > > > > > > > > > So how can you help? > > > > > > Get the Gtk2Hs sources and write something! :-) > > > > > > The easiest way for us to receive contributions is via darcs send, just > > > like ordinary code contributions. There's no need for contributions to > > > be major works, just adding a bit here or there or editing/fixing > > > existing stuff is great. > > > > > > If you don't want to use darcs then just email > > > gtk...@li... with your changes. > > > > > > Details: > > > > > > * Get the Gtk2Hs sources with darcs: > > > darcs get --partial http://darcs.haskell.org/gtk2hs/ > > > > > > * install txt2tags: http://txt2tags.sourceforge.net/download.html > > > > > > * Workflow: > > > 1. cd gtk2hs/docs/tutorial/intro/ > > > 2. $EDITOR intro.t2t > > > 3. make > > > 4. { repeat steps 2-3 until satisfied } > > > 5. darcs record > > > 6. darcs send > > > > > > > > > If you have particular ideas about how a tutorial should be structured > > > I'd be glad to hear them. > > > > > > Any questions or other suggestions? > > > > > > Duncan > > > > > > > > > ------------------------------------------------------------------------- > > Take Surveys. Earn Cash. Influence the Future of IT > > Join SourceForge.net's Techsay panel and you'll get the chance to share your > > opinions on IT & business topics through brief surveys - and earn cash > > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > > _______________________________________________ > > Gtk2hs-users mailing list > > Gtk...@li... > > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users > |
From: Duncan C. <dun...@wo...> - 2006-11-27 19:50:24
|
On Mon, 2006-11-27 at 15:32 +0100, Hans van Thiel wrote: > Hello All, > > The tutorial outline looks good to me, and I'd be happy to contribute. > However, since I'm not a subject matter expert, I'd need some pointers > to basic texts. Maybe just about GTK+, in those cases where Gth2Hs usage > is a port of the same principle. The problem here seems to be, that > those who know don't like to write, and those who'd like to write don't > know (in my case anyway :-)). Yes, that is a problem to some extent. Also, while the Gtk2Hs developers are good at knowing if the tutorial is technically correct, we're not necessarily the best people to make sure that the material is explained in a easy way or a sensible order. > But with some good starting points, and some assured feed back > (quality control), it seems feasible. Certainly. Since we're keeping it all in darcs it's easy for other people to review and make additional changes. Have you tried checking out the Gtk2Hs darcs repo yet? I really recommend it. darcs is a great collaboration tool. The best way to use it is to record each set of logically related changes as one patch - rather that writing everything and then recording it in one go. So you can record many patches and then use: darcs send --edit-description to send them all in one batch. The --edit-description flag allows you to edit the email to which all the patches will be attached, so you can give a general description of what the patches do. (You need local email working for 'darcs send' to work, otherwise use --output=blah.patch and attach that in an email) > I also think there are some good Gtk2hs examples available, and imo we > should use these whenever possible. Yes, and of course any examples created for the purpose of a tutorial can be included in the demo collection. For example the hello world demo and glade demo should be made to match whatever is used in the tutorial. The demos are in darcs too of course so it's easy to send in changes to those. Duncan |
From: Hans v. T. <hth...@zo...> - 2006-11-28 21:16:00
|
Hello Duncan, Thanks. I've installed darcs and I'll get to work on it. Regards, Hans On Mon, 2006-11-27 at 19:49 +0000, Duncan Coutts wrote: > On Mon, 2006-11-27 at 15:32 +0100, Hans van Thiel wrote: > > Hello All, > > > > The tutorial outline looks good to me, and I'd be happy to contribute. > > However, since I'm not a subject matter expert, I'd need some pointers > > to basic texts. Maybe just about GTK+, in those cases where Gth2Hs usage > > is a port of the same principle. The problem here seems to be, that > > those who know don't like to write, and those who'd like to write don't > > know (in my case anyway :-)). > > Yes, that is a problem to some extent. Also, while the Gtk2Hs developers > are good at knowing if the tutorial is technically correct, we're not > necessarily the best people to make sure that the material is explained > in a easy way or a sensible order. > > > But with some good starting points, and some assured feed back > > (quality control), it seems feasible. > > Certainly. Since we're keeping it all in darcs it's easy for other > people to review and make additional changes. > > Have you tried checking out the Gtk2Hs darcs repo yet? I really > recommend it. darcs is a great collaboration tool. The best way to use > it is to record each set of logically related changes as one patch - > rather that writing everything and then recording it in one go. > > So you can record many patches and then use: > darcs send --edit-description > to send them all in one batch. The --edit-description flag allows you to > edit the email to which all the patches will be attached, so you can > give a general description of what the patches do. > > (You need local email working for 'darcs send' to work, otherwise use > --output=blah.patch and attach that in an email) > > > I also think there are some good Gtk2hs examples available, and imo we > > should use these whenever possible. > > Yes, and of course any examples created for the purpose of a tutorial > can be included in the demo collection. For example the hello world demo > and glade demo should be made to match whatever is used in the tutorial. > > The demos are in darcs too of course so it's easy to send in changes to > those. > > Duncan > |
From: Hans v. T. <hth...@zo...> - 2006-12-05 13:25:46
Attachments:
index.t2t
|
Hello All, I've sent a first draft of the first part in txt2tags format to darcs and I attach it here too. Duncan, when I run make I get the error message: make: *** No rule to make target '../../gtk/Graphics/UI/Gtk.hi, needed by '../exports' Stop In the file index.t2t I've noted some further problems and questions as comments. I think that what the beginning user needs to know most is how the Gtk+ object oriented specification with classes and instances, attributes and methods is mapped into the Haskell type system and how the api reflects this. After that a global overview of what events are and what the difference is with signals. (From the api I gather the user can also cause things to happen directly from events (?). Maybe somebody can explain these two subjects and/or point to some source of information. Thanks in advance. Regards, Hans van Thiel On Sat, 2006-11-25 at 20:55 +0000, Duncan Coutts wrote: > Hia folks, > > Several months ago we had a longish thread here about writing a > tutorial. We discussed tools etc and came to some conclusions on that > topic. What didn't happen however was any actual writing! :-) > > So that now that we do have the technology I'd like to ask again for > help writing an intro tutorial (or indeed tutorials on any more advanced > aspect of build GUI apps with Gtk2Hs). > > Thanks to Hans van Thiel porting a Glade tutorial from C to > Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to > approval from Hans and the original author, that tutorial will be hosted > on the Gtk2Hs site. > > So here's the setup: > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via > latex) output. We also have a post-processor program that does syntax > highlighting of Haskell code and adds hyperlinks to the haddock > documentation. > > Here's an example. It's just a skeleton of a tutorial, but you get the > idea: > http://haskell.org/gtk2hs/docs/tutorial/intro/ > > And the source: > http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t > > > So how can you help? > > Get the Gtk2Hs sources and write something! :-) > > The easiest way for us to receive contributions is via darcs send, just > like ordinary code contributions. There's no need for contributions to > be major works, just adding a bit here or there or editing/fixing > existing stuff is great. > > If you don't want to use darcs then just email > gtk...@li... with your changes. > > Details: > > * Get the Gtk2Hs sources with darcs: > darcs get --partial http://darcs.haskell.org/gtk2hs/ > > * install txt2tags: http://txt2tags.sourceforge.net/download.html > > * Workflow: > 1. cd gtk2hs/docs/tutorial/intro/ > 2. $EDITOR intro.t2t > 3. make > 4. { repeat steps 2-3 until satisfied } > 5. darcs record > 6. darcs send > > > If you have particular ideas about how a tutorial should be structured > I'd be glad to hear them. > > Any questions or other suggestions? > > Duncan > |
From: Axel S. <A....@ke...> - 2006-12-05 13:48:37
|
Hi Hans, On Tue, 2006-12-05 at 14:28 +0100, Hans van Thiel wrote: > Hello All, > > I've sent a first draft of the first part in txt2tags format to darcs > and I attach it here too. Duncan, when I run make I get the error > message: > make: *** No rule to make target '../../gtk/Graphics/UI/Gtk.hi, needed > by '../exports' Stop I looks like you didn't build gtk2hs itself beforehand. Maybe there should be a dependency on that. For now, could you try to say 'make' in the gtk2hs directory? > In the file index.t2t I've noted some further problems and questions as > comments. I think that what the beginning user needs to know most is how > the Gtk+ object oriented specification with classes and instances, > attributes and methods is mapped into the Haskell type system and how > the api reflects this. Yes, that sounds right for a start. > After that a global overview of what events are > and what the difference is with signals. (From the api I gather the user > can also cause things to happen directly from events (?). I think we should not push this difference between events and signals. Basically, the Widget class has a few signals that pass back an Event structure. These could be called events, but, really, they are just plain signals. Maybe we should just settle for a single term, I suppose "signal" could be the right term and "event", "callback", etc should not be used anywhere. > Maybe somebody can explain these two subjects and/or point to some > source of information. Thanks in advance. I think this is all there is to it. Thanks for the draft. The multithreaded issue is also something we need to look into. (sigh) Ta, Axel. > Regards, > > Hans van Thiel > On Sat, 2006-11-25 at 20:55 +0000, Duncan Coutts wrote: > > Hia folks, > > > > Several months ago we had a longish thread here about writing a > > tutorial. We discussed tools etc and came to some conclusions on that > > topic. What didn't happen however was any actual writing! :-) > > > > So that now that we do have the technology I'd like to ask again for > > help writing an intro tutorial (or indeed tutorials on any more advanced > > aspect of build GUI apps with Gtk2Hs). > > > > Thanks to Hans van Thiel porting a Glade tutorial from C to > > Haskell/Gtk2Hs we do now have a tutorial on that subject. Subject to > > approval from Hans and the original author, that tutorial will be hosted > > on the Gtk2Hs site. > > > > So here's the setup: > > > > We keep the tutorials in the Gtk2Hs darcs repo in the txt2tags format. > > > > We have a makefiles that call txt2tags to generate XHTML or PS/PDF (via > > latex) output. We also have a post-processor program that does syntax > > highlighting of Haskell code and adds hyperlinks to the haddock > > documentation. > > > > Here's an example. It's just a skeleton of a tutorial, but you get the > > idea: > > http://haskell.org/gtk2hs/docs/tutorial/intro/ > > > > And the source: > > http://darcs.haskell.org/gtk2hs/docs/tutorial/intro/index.t2t > > > > > > So how can you help? > > > > Get the Gtk2Hs sources and write something! :-) > > > > The easiest way for us to receive contributions is via darcs send, just > > like ordinary code contributions. There's no need for contributions to > > be major works, just adding a bit here or there or editing/fixing > > existing stuff is great. > > > > If you don't want to use darcs then just email > > gtk...@li... with your changes. > > > > Details: > > > > * Get the Gtk2Hs sources with darcs: > > darcs get --partial http://darcs.haskell.org/gtk2hs/ > > > > * install txt2tags: http://txt2tags.sourceforge.net/download.html > > > > * Workflow: > > 1. cd gtk2hs/docs/tutorial/intro/ > > 2. $EDITOR intro.t2t > > 3. make > > 4. { repeat steps 2-3 until satisfied } > > 5. darcs record > > 6. darcs send > > > > > > If you have particular ideas about how a tutorial should be structured > > I'd be glad to hear them. > > > > Any questions or other suggestions? > > > > Duncan > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ Gtk2hs-users mailing list Gtk...@li... https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Duncan C. <dun...@wo...> - 2006-12-05 15:26:38
|
On Tue, 2006-12-05 at 14:28 +0100, Hans van Thiel wrote: > Hello All, > > I've sent a first draft of the first part in txt2tags format to darcs > and I attach it here too. Fantastic! BTW, It looks like the 'darcs send' email didn't come through. You should probably check that your local mail is working. Sadly, just because darcs send completes doesn't guarantee that the mail agent is correctly configured. Usually the problem is that the local mail agent hasn't been set up to forward outgoing mail to the ISP's smtp server. For example with ssmtp one has to set the mailhub setting in /etc/ssmtp/ssmtp.conf It's good to get darcs send working as it makes life much easier when doing minor edits. It gets kind of tiring to send a new email with an attachment for a few one line fixes. :-) So I'll hold of adding the attached version for a couple days to give you a chance to darcs send again (- that way you get proper credit in the change log!) > Duncan, when I run make I get the error > message: > make: *** No rule to make target '../../gtk/Graphics/UI/Gtk.hi, needed > by '../exports' Stop Yeah, as Axel said it's because it needs everything to be built first. Here's the quick fix: download this file to your gtk2hs/docs/tutorial/ directory and then 'make' again. http://haskell.org/~duncan/gtk2hs/exports Alternatively you can do the build yourself. Build instructions are basically: (from the root of the build tree) autoreconf ./configure --enable-hcflags=-O0 make http://haskell.org/gtk2hs/development/#development What it's actually doing is using gtk/Graphics/UI/Gtk.hi to generate an index of all the exported Gtk2Hs functions and using that to link functions in Haskell code snippets to their corresponding haddock documentation. Cool stuff, but it does need Gtk2Hs to be built first. So the short-cut is just to grab that exports file that I generated. I've not included any html header, footer or .ccs file in the docs dir so the docs come out looking fairly ordinary. I should fix that. I do have a header/footer that we use for the Gtk2Hs site which includes CSS for the Haskell syntax highlighting etc. > In the file index.t2t I've noted some further problems and questions as > comments. Ok, great. > I think that what the beginning user needs to know most is how > the Gtk+ object oriented specification with classes and instances, > attributes and methods is mapped into the Haskell type system and how > the api reflects this. Yes, this is important for understanding. Though I'm not sure it should go first. I often think starting with an example helps (eg hello world) before going into the detailed explanation of the structure. > After that a global overview of what events are and what the > difference is with signals. As Axel said, we try not to distinguish between events and signals. Technically, events are things that come directly from X11, like mouse clicks etc however Gtk+ maps all of these into signals on GtkWidget, so this allows us to say that there are just signals. > (From the api I gather the user can also cause things to happen > directly from events (?). Not sure what you mean here. So basically we have, objects which are OOP style objects with mutable state. The object types form a hierarchy, for example Widget is an Object and Button is a Widget (and an object). Objects can have attributes, signals and methods. Each object type has a couple type casting functions (for safe upcasting and checked downcasting). Most object types have a constructor function so you can actually make one (though some are abstract, like Widget or Object). Attributes use the syntax: get object attr set object [ attr1 := value1, attr2 := value2 ] At the moment for many attributes there are also methods that duplicate the functionality. We intend to deprecate these methods in future so we should encourage people to use the attribute syntax rather than the widgetGetFoo / widgetSetBar style. For signals, there's an on<Signal> and after<Signal> function per signal (in the future this will change slightly but not significantly). Duncan |
From: Thomas v. N. <tr...@cs...> - 2006-12-05 18:33:19
|
Hi, Next week I'll be giving a presentation on building GUIs in Haskell. I wanted to include a nice logo of Gtk2Hs but the only one I could find was this one: http://www.haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-with-lambda-nobg.png Is there any other (larger) logo available somewhere? Thanks! Thomas |
From: Duncan C. <dun...@wo...> - 2006-12-05 21:36:11
|
On Tue, 2006-12-05 at 19:35 +0100, Thomas van Noort wrote: > Hi, > > Next week I'll be giving a presentation on building GUIs in Haskell. Cool! Will the slides be available? > I wanted to include a nice logo of Gtk2Hs but the only one I could find > was this one: > > http://www.haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-with-lambda-nobg.png > > Is there any other (larger) logo available somewhere? Since you ask so nicely... http://haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-large-nobg.png (I've got the GIMP .xcf version too in case anyone else ever wants it.) Duncan |
From: Thomas v. N. <tr...@cs...> - 2006-12-06 10:42:48
|
The slides will be available in about 10 days. Thanks for the logo! I still have a question about memory management. There are two problems with FFI: * C values have to be cleaned up explicitly, which is implemented using ForeignPtrs in Haskell. A reference scheme is used to inform the Haskell garbage collector that the C finalizer can be called. * Haskell values can be garbage collected, or moved around, which can cause a C reference to a Haskell value to fail when it is used. This is solved using StablePtrs, which are specially treated by the Haskell garbage collector. However, nothing is said about how Gtk2Hs solves the second problem. The story about memory management on the Gtk2Hs site only mentions ForeignPtrs, which solves the first problem. Can you confirm that Gtk2Hs uses StablePtrs to solve the second problem? Regards, Thomas On Tue, 2006-12-05 at 22:36 +0100, Duncan Coutts wrote: > On Tue, 2006-12-05 at 19:35 +0100, Thomas van Noort wrote: > > Hi, > > > > Next week I'll be giving a presentation on building GUIs in Haskell. > > Cool! > > Will the slides be available? > > > I wanted to include a nice logo of Gtk2Hs but the only one I could find > > was this one: > > > > http://www.haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-with-lambda-nobg.png > > > > Is there any other (larger) logo available somewhere? > > Since you ask so nicely... > > http://haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-large-nobg.png > > (I've got the GIMP .xcf version too in case anyone else ever wants it.) > > Duncan > |
From: Axel S. <A....@ke...> - 2006-12-06 11:00:13
|
On Wed, 2006-12-06 at 11:42 +0100, Thomas van Noort wrote: > The slides will be available in about 10 days. Thanks for the logo! > > I still have a question about memory management. There are two problems > with FFI: > > * C values have to be cleaned up explicitly, which is implemented using > ForeignPtrs in Haskell. A reference scheme is used to inform the Haskell > garbage collector that the C finalizer can be called. > * Haskell values can be garbage collected, or moved around, which can > cause a C reference to a Haskell value to fail when it is used. This is > solved using StablePtrs, which are specially treated by the Haskell > garbage collector. > > However, nothing is said about how Gtk2Hs solves the second problem. The > story about memory management on the Gtk2Hs site only mentions > ForeignPtrs, which solves the first problem. Can you confirm that Gtk2Hs > uses StablePtrs to solve the second problem? We do use StablePtrs but there are very few places where they are required. Most Haskell data is kept in function closures, that is, whenever you register a callback, you pass in a function that contains Haskell data. This function pointer is freed once Gtk or the Haskell programmer disconnects the signal. At this point, the whole function closure is garbage collected. At the moment, we only need StablePtr in the store that backs up the TreeView widget. Hope this helps, Axel. > Regards, > Thomas > > On Tue, 2006-12-05 at 22:36 +0100, Duncan Coutts wrote: > > On Tue, 2006-12-05 at 19:35 +0100, Thomas van Noort wrote: > > > Hi, > > > > > > Next week I'll be giving a presentation on building GUIs in Haskell. > > > > Cool! > > > > Will the slides be available? > > > > > I wanted to include a nice logo of Gtk2Hs but the only one I could find > > > was this one: > > > > > > http://www.haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-with-lambda-nobg.png > > > > > > Is there any other (larger) logo available somewhere? > > > > Since you ask so nicely... > > > > http://haskell.org/~duncan/gtk2hs/Gtk2Hs-logo-large-nobg.png > > > > (I've got the GIMP .xcf version too in case anyone else ever wants it.) > > > > Duncan > > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share your > opinions on IT & business topics through brief surveys - and earn cash > http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > Gtk2hs-users mailing list > Gtk...@li... > https://lists.sourceforge.net/lists/listinfo/gtk2hs-users |
From: Hans v. T. <hth...@zo...> - 2006-12-06 15:01:41
|
On Tue, 2006-12-05 at 16:26 +0100, Duncan Coutts wrote: > On Tue, 2006-12-05 at 14:28 +0100, Hans van Thiel wrote: > > Hello All, > > > > I've sent a first draft of the first part in txt2tags format to darcs > > and I attach it here too. > > Fantastic! > > BTW, It looks like the 'darcs send' email didn't come through. You > should probably check that your local mail is working. Sadly, just > because darcs send completes doesn't guarantee that the mail agent is > correctly configured. Usually the problem is that the local mail agent > hasn't been set up to forward outgoing mail to the ISP's smtp server. > For example with ssmtp one has to set the mailhub setting > in /etc/ssmtp/ssmtp.conf I'm using the standard package for fc6 and this should work out of the box, especially since configuring sendmail is not part of the standard fc6 distribution. Maybe it's something simple, to do with security settings. I'll look into it. Meanwhile, I hope you got the text in a readable form. > > It's good to get darcs send working as it makes life much easier when > doing minor edits. It gets kind of tiring to send a new email with an > attachment for a few one line fixes. :-) > > So I'll hold of adding the attached version for a couple days to give > you a chance to darcs send again (- that way you get proper credit in > the change log!) > > > Duncan, when I run make I get the error > > message: > > make: *** No rule to make target '../../gtk/Graphics/UI/Gtk.hi, needed > > by '../exports' Stop > > Yeah, as Axel said it's because it needs everything to be built first. > > Here's the quick fix: download this file to your gtk2hs/docs/tutorial/ > directory and then 'make' again. > http://haskell.org/~duncan/gtk2hs/exports > This doesn't work either, but I suspect it's all because I use a local copy of the gtk2hs directory. I've installed ghc 6.6, Gtk2Hs and the Gtk2Hs docs as standard fc6 packages (but not Haddock yet) and I don't want to change anything there manually. But I suppose substituting absolute filepaths in the make files would fix it. Meanwhile, a question for the developers which should be addressed in the intro tutorial. Compiling the Hello World example with ghc 6.6 works as the tutorial outline says, but ghci needs a no threaded flag. (see my draft). But when I tested the Glade examples, with ghc 6.4 and gtk2hs under fedora core 5 two months ago, ghci worked just fine. So, what is needed for ghci, or are the current gtk2hs and interactive compiler versions incompatible? And is there a way to use Hugs? Both fc5 and fc6 versions couldn't find the import graphics module, but I suppose there's more to this than that? And maybe there should also be a command for YHC as well as GHC? > Alternatively you can do the build yourself. Build instructions are > basically: (from the root of the build tree) > autoreconf > ./configure --enable-hcflags=-O0 > make > > http://haskell.org/gtk2hs/development/#development > > What it's actually doing is using gtk/Graphics/UI/Gtk.hi to generate an > index of all the exported Gtk2Hs functions and using that to link > functions in Haskell code snippets to their corresponding haddock > documentation. Cool stuff, but it does need Gtk2Hs to be built first. So > the short-cut is just to grab that exports file that I generated. > > I've not included any html header, footer or .ccs file in the docs dir > so the docs come out looking fairly ordinary. I should fix that. I do > have a header/footer that we use for the Gtk2Hs site which includes CSS > for the Haskell syntax highlighting etc. > > > In the file index.t2t I've noted some further problems and questions as > > comments. > > Ok, great. > > > I think that what the beginning user needs to know most is how > > the Gtk+ object oriented specification with classes and instances, > > attributes and methods is mapped into the Haskell type system and how > > the api reflects this. > > Yes, this is important for understanding. Though I'm not sure it should > go first. I often think starting with an example helps (eg hello world) > before going into the detailed explanation of the structure. Done. > > After that a global overview of what events are and what the > > difference is with signals. > > As Axel said, we try not to distinguish between events and signals. > > Technically, events are things that come directly from X11, like mouse > clicks etc however Gtk+ maps all of these into signals on GtkWidget, so > this allows us to say that there are just signals. Ok, that's pretty clear. > > (From the api I gather the user can also cause things to happen > > directly from events (?). > > Not sure what you mean here. Sorry, got confused here. > > So basically we have, objects which are OOP style objects with mutable > state. The object types form a hierarchy, for example Widget is an > Object and Button is a Widget (and an object). Objects can have > attributes, signals and methods. Each object type has a couple type > casting functions (for safe upcasting and checked downcasting). Most > object types have a constructor function so you can actually make one > (though some are abstract, like Widget or Object). Thanks, this helps. And is it true that an object class is always a Haskell type class and that an instance corresponds to a Haskell type? And 'self' in type declarations is borrowed from OO and stands for the handle of an instance (actually its type)? > > Attributes use the syntax: > get object attr > set object [ attr1 := value1, attr2 := value2 ] > > At the moment for many attributes there are also methods that duplicate > the functionality. We intend to deprecate these methods in future so we > should encourage people to use the attribute syntax rather than the > widgetGetFoo / widgetSetBar style. Again, very clear. > > For signals, there's an on<Signal> and after<Signal> function per signal > (in the future this will change slightly but not significantly). Another handy rule. The main purpose of the introduction imo is to provide a guide to the api so the user can quickly and correctly pick and use what he or she wants, from the available widgets. I hope to finish a complete first draft in a week or two... :-) A question for Thomas van Noort: any way to view your presentation on building GUIs in Haskell? Sounds interesting! To others as well, if you have anything which might help, especially problems which you have encountered and solved, please post them here. Regards, Hans > > Duncan > |
From: Axel S. <A....@ke...> - 2006-12-06 19:40:35
|
On Wed, 2006-12-06 at 15:38 +0100, Hans van Thiel wrote: > > > > Here's the quick fix: download this file to your gtk2hs/docs/tutorial/ > > directory and then 'make' again. > > http://haskell.org/~duncan/gtk2hs/exports > > > This doesn't work either, but I suspect it's all because I use a local > copy of the gtk2hs directory. I've installed ghc 6.6, Gtk2Hs and the > Gtk2Hs docs as standard fc6 packages (but not Haddock yet) and I don't > want to change anything there manually. But I suppose substituting > absolute filepaths in the make files would fix it. Duncan knows more about how syntax highlighting is done. But it might be easier if you simply use darcs to get the latest Gtk2Hs and compile it yourself. It is pretty straightforward these days, the INSTALL file is nearly up to date (except that it mentions CVS at the end which is now darcs). > Meanwhile, a question for the developers which should be addressed in > the intro tutorial. Compiling the Hello World example with ghc 6.6 > works as the tutorial outline says, but ghci needs a no threaded flag. > (see my draft). But when I tested the Glade examples, with ghc 6.4 and > gtk2hs under fedora core 5 two months ago, ghci worked just fine. So, > what is needed for ghci, or are the current gtk2hs and interactive > compiler versions incompatible? The problem is that ghc 6.6 now uses the threaded RTS by default whereas you had to request this with 6.4 explicitly. Gtk2Hs doesn't work with the threaded RTS, although I forgot why exactly and if we can work around this issue somehow. The ideal solution is to integrate the Gtk+ event loop with the GHC scheduler, but GHC doesn't seem to provide this possibility right now. > And is there a way to use Hugs? Both fc5 and fc6 versions couldn't > find the import graphics module, but I suppose there's more to this > than that? And maybe there should also be a command for YHC as well as > GHC? Both Hugs and Yhc don't support the "wrapper" FFI functions AFAIK. Thus, we cannot support these platforms at this point. > > > > For signals, there's an on<Signal> and after<Signal> function per signal > > (in the future this will change slightly but not significantly). > Another handy rule. The main purpose of the introduction imo is to > provide a guide to the api so the user can quickly and correctly pick > and use what he or she wants, from the available widgets. > I hope to finish a complete first draft in a week or two... :-) That'd be great and go into our release which we hopefully manage to do before Xmas. Thanks in advance, Axel. |
From: Duncan C. <dun...@wo...> - 2006-12-06 22:00:26
|
On Wed, 2006-12-06 at 15:38 +0100, Hans van Thiel wrote: > On Tue, 2006-12-05 at 16:26 +0100, Duncan Coutts wrote: > > On Tue, 2006-12-05 at 14:28 +0100, Hans van Thiel wrote: > > BTW, It looks like the 'darcs send' email didn't come through. You > > should probably check that your local mail is working. Sadly, just > > because darcs send completes doesn't guarantee that the mail agent is > > correctly configured. Usually the problem is that the local mail agent > > hasn't been set up to forward outgoing mail to the ISP's smtp server. > > For example with ssmtp one has to set the mailhub setting > > in /etc/ssmtp/ssmtp.conf > I'm using the standard package for fc6 and this should work out of the > box, especially since configuring sendmail is not part of the standard > fc6 distribution. Maybe it's something simple, to do with security > settings. I'll look into it. It's always a manual configuration step to tell your local mail agent the dns name of your ISP's smtp server. So sadly it can't work 'out of the box'. It needn't be sendmail, any simple smtp forwarding agent will do, but it does need that one item to configure it properly. I expect fc6 uses ssmtp or some other similar simple smtp forwarding agent. > Meanwhile, I hope you got the text in a readable form. Yes. > > Here's the quick fix: download this file to your gtk2hs/docs/tutorial/ > > directory and then 'make' again. > > http://haskell.org/~duncan/gtk2hs/exports > > > This doesn't work either, but I suspect it's all because I use a local > copy of the gtk2hs directory. I've installed ghc 6.6, Gtk2Hs and the > Gtk2Hs docs as standard fc6 packages (but not Haddock yet) and I don't > want to change anything there manually. But I suppose substituting > absolute filepaths in the make files would fix it. You are using the darcs version of Gtk2Hs right? If it doesn't work, send (just to me) the error message and what you did to get it. > Meanwhile, a question for the developers which should be addressed in > the intro tutorial. Compiling the Hello World example with ghc 6.6 > works as the tutorial outline says, but ghci needs a no threaded flag. > (see my draft). But when I tested the Glade examples, with ghc 6.4 and > gtk2hs under fedora core 5 two months ago, ghci worked just fine. So, > what is needed for ghci, or are the current gtk2hs and interactive > compiler versions incompatible? Yeah, as Axel said, ever since ghc-6.4.2, by default ghci has been using the threaded rts. At the moment Gtk2Hs cannot safely be used with the threaded rts because we cannot guarantee that all calls to Gtk2Hs functions will occur on the same OS thread. This is essential because like most other GUI libs, Gtk+ is essentially single-threaded. There are a number of potential solutions but none are easy to implement, so for the moment we're stuck with the single threaded rts and thus without ghci. > And is there a way to use Hugs? Both fc5 and fc6 versions couldn't > find the import graphics module, but I suppose there's more to this > than that? And maybe there should also be a command for YHC as well as > GHC? I think that YHC does now support the full FFI so in future it may be possible. In practise the issue is probably more to do with the build system. I wouldn't like to try using compilers other than ghc until we have got Gtk2Hs building using Cabal. > > So basically we have, objects which are OOP style objects with mutable > > state. The object types form a hierarchy, for example Widget is an > > Object and Button is a Widget (and an object). Objects can have > > attributes, signals and methods. Each object type has a couple type > > casting functions (for safe upcasting and checked downcasting). Most > > object types have a constructor function so you can actually make one > > (though some are abstract, like Widget or Object). > > Thanks, this helps. And is it true that an object class is always a > Haskell type class and that an instance corresponds to a Haskell type? > And 'self' in type declarations is borrowed from OO and stands for the > handle of an instance (actually its type)? We model the OOP classes with *both* a Haskell type class and a data type that is a 'canonical' instance of that class. Here's an example: class WidgetClass w data Widget = ... instance WidgetClass Widget Then a Button is a subclass of Widget: class WidgetClass w => ButtonClass w data Button = ... instance WidgetClass Button instance ButtonClass Button So the widget class is the class of types which inherit from widget, so that obviously includes the Widget type itself and also the Button type. So the Button type is an instance of both Widget and Button. The ButtonClass declaration says that to be a button, the type must also be a widget. So this explains the type signature: widgetShow :: WidgetClass self => self -> IO () This function works for widget types and all types that inherit from widget. > The main purpose of the introduction imo is to provide a guide to the > api so the user can quickly and correctly pick and use what he or she > wants, from the available widgets. Yes, I think that's what beginners need. > I hope to finish a complete first draft in a week or two... :-) Cool. As Axel, says, hopefully we'll have a release ready to go with it :-) Duncan |
From: Neil M. <ndm...@gm...> - 2006-12-06 22:57:54
|
Hi > > And is there a way to use Hugs? Both fc5 and fc6 versions couldn't > > find the import graphics module, but I suppose there's more to this > > than that? And maybe there should also be a command for YHC as well as > > GHC? > > I think that YHC does now support the full FFI so in future it may be > possible. In practise the issue is probably more to do with the build > system. I wouldn't like to try using compilers other than ghc until we > have got Gtk2Hs building using Cabal. I think this would be a nice thing to tackle at the hackathon. My other goal is to get Yhc+Cabal+base all happy, so this is probably a nice thing to work on as well. Thanks Neil |