From: Matthew W. <ma...@al...> - 2004-04-28 17:42:10
|
In my attempt to port the examples/gtk-demo/the gtk tutorial to gtk2hs I've noticed a few widgets we don't seem to have, including: - *ButtonBox - ColorSelectionDialog and friends - FontSelectionDialog and friends Is this really happening or is it just me? If it's not just me, how does one go about wrapping extra widgets with gtk2hs? |
From: Axel S. <A....@ke...> - 2004-04-28 18:03:30
|
On Wed, Apr 28, 2004 at 06:42:05PM +0100, Matthew Walton wrote: > In my attempt to port the examples/gtk-demo/the gtk tutorial to gtk2hs > I've noticed a few widgets we don't seem to have, including: > > - *ButtonBox > - ColorSelectionDialog and friends > - FontSelectionDialog and friends > > Is this really happening or is it just me? > > If it's not just me, how does one go about wrapping extra widgets with > gtk2hs? Find the right directory in gtk/. Copy an existing widget file. Add a type to hierarchy.list if not already present. Try to follow the syntax of the c2hs hooks. Write to the list as soon as you encounter problems... Note that gtk2hs doesn't contain deprecated widgets or widgets which might be deprecated or removed in the future. This probably doesn't help. Sorry. Axel. |
From: Matthew W. <ma...@al...> - 2004-04-28 18:10:49
|
Axel Simon wrote: > On Wed, Apr 28, 2004 at 06:42:05PM +0100, Matthew Walton wrote: > >>In my attempt to port the examples/gtk-demo/the gtk tutorial to gtk2hs >>I've noticed a few widgets we don't seem to have, including: >> >>- *ButtonBox >>- ColorSelectionDialog and friends >>- FontSelectionDialog and friends >> >>Is this really happening or is it just me? >> >>If it's not just me, how does one go about wrapping extra widgets with >>gtk2hs? > > > Find the right directory in gtk/. Copy an existing widget file. Add a type to > hierarchy.list if not already present. Try to follow the syntax of the c2hs hooks. > Write to the list as soon as you encounter problems... Okay, I'll have a go. > Note that gtk2hs doesn't contain deprecated widgets or widgets which might be > deprecated or removed in the future. None of the widgets I'm currently missing are deprecated or planned to be, as far as I'm aware. > This probably doesn't help. Sorry. No, that's fine. Thanks. |
From: Duncan C. <dun...@wo...> - 2004-04-28 18:21:32
|
On Wed, 2004-04-28 at 18:42, Matthew Walton wrote: > In my attempt to port the examples/gtk-demo/the gtk tutorial to gtk2hs > I've noticed a few widgets we don't seem to have, including: > > - *ButtonBox > - ColorSelectionDialog and friends > - FontSelectionDialog and friends > > Is this really happening or is it just me? That seems right. > If it's not just me, how does one go about wrapping extra widgets with > gtk2hs? I'm glad you asked! :-) It's mostly a case of looking at the existing code and following by example. however here's a quick guide: Check that the widget you want to wrap is not depreciated - we don't bother adding depreciated stuff. Check that your widget has been added into the class hierarchy file: tools/hierarchyGen/hierarchy.list. In your case, all the ones you mentioned are already there. For a new widget create a new .chs file with the same name as the widget (although we leave off the "Gtk" prefix), eg "ButtonBox.chs". The files are split into subdirectories (under the gtk directory) by rough categories. you'll have to figure out which seems most appropriate. Ask if you are unsure. The module has a .chs extension rather than .hs because it gets run through the c2hs preprocessor to produce a .hs file. c2hs is a tool that provides a higher level interface to Haskell's foreign function interface and helps to make sure that we call C functions with the right number and types of arguments. You can probably just follow the examples but the manual is here if you need it: http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs.html in particular chapter 3 http://www.cse.unsw.edu.au/~chak/haskell/c2hs/docu/c2hs-3.html As Axel suggests it'll be easer to use an existing file as a template. I follow this procedure when binding a new module: 1. make the list of exported functions & types, converting gtk_this_kind_of_name to thisKindOfName 2. make the function type signatures, so for example: Duncan |
From: Duncan C. <dun...@wo...> - 2004-04-28 19:03:03
|
[oops I sent before I'd finished explaining. Where was I...] BTW this all assumes you're working on the latest cvs copy of gtk2hs, check the sourceforge project page for details of how to checkout the latest cvs code. I follow this procedure when binding a new module: 1. Browse to the appropriate page in the gtk API reference http://developer.gnome.org/doc/API/2.0/gtk/ch01.html so we can keep an eye on the C types and so we can copy&paste the function names. 2. Make the list of exported functions & types, converting gtk_this_kind_of_name to thisKindOfName 3. Make the function type signatures. For example: if the C function had a prototype: gboolean gtk_someobject_adjust_thing (GtkSomeObject obj, gint n); the corresponding Haskell decleration would be someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool or if the return type were void we'd have the result type IO () sometimes you might see this kind of function get the type someobjectAdjustThing :: => SomeObject -> Int -> IO Bool We would do this when we know that the object is not going to be derived from as is often the case with objects that derive directly from GObject. In your case ButtonBox has two classes that derive from it so you should use the former style. 4. The next thing I do is for each function to add in a call to the C function that we are wrapping, so our example would now look like this: someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool someobjectAdjustThing obj thingValue = {# call gtk_someobject_adjust_thing #} (the "gtk_" prefix is optional but it is just as easy to leave it in if you're copying it from the gtk api reference web page) You'll also see calls like {# call unsafe gtk_someobject_adjust_thing #} which can be used when we can guarantee that the C function call will not make any calls back into Haskell land (think signals/callbacks or the glib main loop). This is supposed to give a slight performance benefit. It is generally safe for simple 'get' methods. The existing code is your best guide here - or if you really want you can look at the C code itself. (http://cvs.gnome.org/viewcvs/gtk+/) 5. Finally I add in any necessary conversion/marshaling code. For our example it would be: someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool someobjectAdjustThing obj thingValue = liftM toBool $ {# call gtk_someobject_adjust_thing #} (toSomeObject obj) (fromIntegral thingValue) We need to call toSomeObject to convert our SomeObjectClass obj to a simple SomeObject type. 6. Add your new module into gtk/general/Gtk.hs so that it will be exported and so that the build system will compile your module when you run make. You need to add a "module SomeObject," line as well as an "import SomeObject" line in the appropriate places. 7. Try and compile + fix type errors. Assuming that you've previously done a complete build (autoconf-2.58; ./configure; make) then cd to the gtk directory and make from there. (BTW I say autoconf-2.58 because I know autoconf-2.13 is too old. During development I sometimes use ./configure --with-hcflags=-H180m to override the default of doing optimised builds which take much longer.) I usually get type errors because of oversights when adding marshaling code. If you get type errors you can't figure out, it often helps to look at the generated .hs file because that includes the types that c2hs has assigned to the raw C functions at the bottom of the file. 8. When it builds ok, it'd be nice to add demo code for that widget, to give examples of how to use it and just to make sure that things are really working. Look in the demo directory for template Makefiles. For a new demo you'll also need to add it to the list in the top level Makefile. 9. Send the new files and patches against existing files to this list so that someone with cvs commit access can commit it. Feel free to ask questions if you get stuck or want advice. When you've demonstrated your uber gtk2hs binding skills (or Axel gets tired of reviewing and committing your patches!) you'll probably get cvs commit access yourself. Duncan |
From: Matthew W. <ma...@al...> - 2004-04-28 21:17:44
|
Okay, well I'm barging along fairly well with ButtonBox, although I'm not entirely sure what to do with the functionality that's been deprecated from method calls and moved into style properties instead. I also need to implement HButtonBox and VButtonBox so I can actually test things. In the mean time, I'm working on a fresh checkout from CVS, but is anyone else getting a lot of warnings from Gtk.hs like: Warning: 'iconSizeMenu' is exported by 'module IconFactory' and 'module Image' It doesn't *look* like something I did... seems to still build okay, just ghc isn't very happy. Duncan Coutts wrote: > [oops I sent before I'd finished explaining. Where was I...] > > BTW this all assumes you're working on the latest cvs copy of gtk2hs, > check the sourceforge project page for details of how to checkout the > latest cvs code. > > > I follow this procedure when binding a new module: > > 1. Browse to the appropriate page in the gtk API reference > http://developer.gnome.org/doc/API/2.0/gtk/ch01.html > so we can keep an eye on the C types and so we can copy&paste the > function names. > > 2. Make the list of exported functions & types, converting > gtk_this_kind_of_name to thisKindOfName > > 3. Make the function type signatures. For example: if the C function > had a prototype: > gboolean gtk_someobject_adjust_thing (GtkSomeObject obj, gint n); > the corresponding Haskell decleration would be > > someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool > > or if the return type were void we'd have the result type IO () > sometimes you might see this kind of function get the type > > someobjectAdjustThing :: => SomeObject -> Int -> IO Bool > > We would do this when we know that the object is not going to be derived > from as is often the case with objects that derive directly from > GObject. In your case ButtonBox has two classes that derive from it so > you should use the former style. > > 4. The next thing I do is for each function to add in a call to the C > function that we are wrapping, so our example would now look like this: > > someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool > someobjectAdjustThing obj thingValue = > {# call gtk_someobject_adjust_thing #} > > (the "gtk_" prefix is optional but it is just as easy to leave it in if > you're copying it from the gtk api reference web page) > > You'll also see calls like {# call unsafe gtk_someobject_adjust_thing #} > which can be used when we can guarantee that the C function call will > not make any calls back into Haskell land (think signals/callbacks or > the glib main loop). This is supposed to give a slight performance > benefit. It is generally safe for simple 'get' methods. The existing > code is your best guide here - or if you really want you can look at the > C code itself. (http://cvs.gnome.org/viewcvs/gtk+/) > > 5. Finally I add in any necessary conversion/marshaling code. For our > example it would be: > > someobjectAdjustThing :: SomeObjectClass obj => obj -> Int -> IO Bool > someobjectAdjustThing obj thingValue = liftM toBool $ > {# call gtk_someobject_adjust_thing #} (toSomeObject obj) > (fromIntegral thingValue) > > We need to call toSomeObject to convert our SomeObjectClass obj to a > simple SomeObject type. > > 6. Add your new module into gtk/general/Gtk.hs so that it will be > exported and so that the build system will compile your module when you > run make. You need to add a "module SomeObject," line as well as an > "import SomeObject" line in the appropriate places. > > 7. Try and compile + fix type errors. Assuming that you've previously > done a complete build (autoconf-2.58; ./configure; make) then cd to the > gtk directory and make from there. > > (BTW I say autoconf-2.58 because I know autoconf-2.13 is too old. During > development I sometimes use ./configure --with-hcflags=-H180m to > override the default of doing optimised builds which take much longer.) > > I usually get type errors because of oversights when adding marshaling > code. If you get type errors you can't figure out, it often helps to > look at the generated .hs file because that includes the types that c2hs > has assigned to the raw C functions at the bottom of the file. > > 8. When it builds ok, it'd be nice to add demo code for that widget, to > give examples of how to use it and just to make sure that things are > really working. Look in the demo directory for template Makefiles. For a > new demo you'll also need to add it to the list in the top level > Makefile. > > 9. Send the new files and patches against existing files to this list so > that someone with cvs commit access can commit it. > > Feel free to ask questions if you get stuck or want advice. > > When you've demonstrated your uber gtk2hs binding skills (or Axel gets > tired of reviewing and committing your patches!) you'll probably get cvs > commit access yourself. |
From: Matthew W. <ma...@al...> - 2004-04-28 21:47:39
|
Okay, I've got HButtonBox and VButtonBox sort-of-mostly working. Having trouble with the patch though... because it includes new files, I'm running into some problems. cvs diff -u is easy enough, but doesn't pick up on new files, and I assume I can't cvs add them to an anonymous repository (obviously). I also can't find a make target that takes me back to the CVS tree state, so if I diff between two checked out trees I'm going to have to clean it out manually... how do you manage?? Diff the files that've changed and include the new ones seperately? I realise I should know how to do this from gtkmm, but I also realised I've never added a new file to that, just modified existing ones. |
From: Duncan C. <dun...@wo...> - 2004-04-28 22:11:09
|
On Wed, 2004-04-28 at 22:47, Matthew Walton wrote: > Okay, I've got HButtonBox and VButtonBox sort-of-mostly working. Good stuff. > I also can't find a make target that takes me back to the CVS tree > state, so if I diff between two checked out trees I'm going to have to > clean it out manually... Not sure what you mean. > how do you manage?? Diff the files that've changed and include the new > ones seperately? That's what I do. There's probably some way of doing it but I've never bothered to work it out. If you had cvs write access you would do cvs add NewModule.chs; cvs commit NewModule.chs Duncan |
From: Matthew W. <ma...@al...> - 2004-04-29 07:26:52
|
Duncan Coutts wrote: >>how do you manage?? Diff the files that've changed and include the new >>ones seperately? > > > That's what I do. There's probably some way of doing it but I've never > bothered to work it out. If you had cvs write access you would do > cvs add NewModule.chs; cvs commit NewModule.chs Well, CVS write access has both advantages and disadvantages. A sense of responsibility being one of the latter. I'll make up a patch with the extra files in and send it along after work. In the mean time it's back to C++ land I go. |
From: Duncan C. <dun...@wo...> - 2004-04-28 22:07:11
|
On Wed, 2004-04-28 at 22:17, Matthew Walton wrote: > Okay, well I'm barging along fairly well with ButtonBox, although I'm > not entirely sure what to do with the functionality that's been > deprecated from method calls and moved into style properties instead. I > also need to implement HButtonBox and VButtonBox so I can actually test > things. We don't do anything explicitly about properties at the moment as all properties can be accessed through objectGetProperty/objectSetProperty. It might be nice to improve that support in the future - wxHaskell has some nice syntax/api in this area. So don't bind the depreciated method calls you can still get/set the properties. > In the mean time, I'm working on a fresh checkout from CVS, but is > anyone else getting a lot of warnings from Gtk.hs like: [snip] > It doesn't *look* like something I did... seems to still build okay, > just ghc isn't very happy. I get that too. It's from the main Gtk module that re-exports every other module. I've not really investigated if it's a problem. It probably means the user would have to explicitly specify which module the function came from if they needed to use it. Duncan |
From: Matthew W. <ma...@al...> - 2004-04-29 07:25:41
|
Duncan Coutts wrote: > We don't do anything explicitly about properties at the moment as all > properties can be accessed through objectGetProperty/objectSetProperty. > It might be nice to improve that support in the future - wxHaskell has > some nice syntax/api in this area. So don't bind the depreciated method > calls you can still get/set the properties. Okay, that's fine then. >>In the mean time, I'm working on a fresh checkout from CVS, but is >>anyone else getting a lot of warnings from Gtk.hs like: > > [snip] > >>It doesn't *look* like something I did... seems to still build okay, >>just ghc isn't very happy. > > > I get that too. It's from the main Gtk module that re-exports every > other module. I've not really investigated if it's a problem. It > probably means the user would have to explicitly specify which module > the function came from if they needed to use it. Well it's not interfering with what I'm doing at the moment, but it would be nice to get rid of it at some point... |