A while back there was a discussion about what version of WxWidgets to target with WxRuby-SWIG. I don''t remember seeing any resolution, but I gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the thinking that WxRuby-SWIG would quickly mature to the point that it could replace WxRuby, and once that was done the focus would shift to working with 2.5.x. I''d like to request that the focus of WxRuby-SWIG switch to targeting 2.5.x. Mostly this is because the Mac OS X support in 2.4.2 is so poor that I''m not even bothering with it until 2.5.x, and the thought of having to wait to support OS X for two phases of development (finishing WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite discouraging, especially since the move to WxRuby-SWIG is taking longer than originally anticipated. But I''m also thinking that, since WxWidgets has some core changes in 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to incorporate those changes. Application code will need to change to adapt to 2.5, and although WxRuby-SWIG hasn''t been expected to introduce changes of its own, this would be a perfect time to incorporate some of the planned features (e.g. label=() vs. set_label()) and only have to break existing code *once.* For those wanting to add classes to WxRuby-SWIG, I would think it would be preferable to just work on the 2.5 version, rather than adding one for 2.4 and then having to revisit it for the change to 2.5. I recognize that 2.5 is currently not regarded as the "stable" release, but for me the problems of the Mac port combined with the bugs in 2.4 (such as missing XRC support for status bars) make 2.5 much more attractive, and I''d like to move to it as soon as possible. Thoughts? Thanks very much to Nick, Kevin, Park, Curt, and the rest for this excellent project. I really appreciate the time you''ve put into it. I''m using it daily and hope to contribute in the future as I become more comfortable with how WxWidgets works, although my C++ is pretty rusty at the moment. :-) Marshall
I tend to agree with Marshall on this. I suspect that by the time WxRuby-SWIG is ready for release, that wxWidgets 2.5.x will also be considered stable. I would also like to see this happen because of the MacOSX issues as well. Thanks! -Robert On 12/17/04 9:06 AM, "Marshall Elfstrand" <melfstrand@maf.org> wrote:> A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don''t remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with > the thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I''d like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that > I''m not even bothering with it until 2.5.x, and the thought of having > to wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I''m also thinking that, since WxWidgets has some core changes in > 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn''t been expected to > introduce changes of its own, this would be a perfect time to > incorporate some of the planned features (e.g. label=() vs. > set_label()) and only have to break existing code *once.* For those > wanting to add classes to WxRuby-SWIG, I would think it would be > preferable to just work on the 2.5 version, rather than adding one for > 2.4 and then having to revisit it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I''d like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you''ve put into it. > I''m using it daily and hope to contribute in the future as I become > more comfortable with how WxWidgets works, although my C++ is pretty > rusty at the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users
I agree with Marshall. I have not touched wxRuby lately because I needed to move to wx 2.5.x to fix a "chicken/egg" condition in 2.4.x printing. Another reason to move to 2.5.x now is the changes to break-up the libs. Also wxPython is using 2.5.3 and we can''t let that lesser language show us up ;) Sean -----Original Message----- From: wxruby-users-bounces@rubyforge.org [mailto:wxruby-users-bounces@rubyforge.org] On Behalf Of Marshall Elfstrand Sent: Friday, December 17, 2004 9:06 AM To: General discussion of wxRuby Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x A while back there was a discussion about what version of WxWidgets to target with WxRuby-SWIG. I don''t remember seeing any resolution, but I gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the thinking that WxRuby-SWIG would quickly mature to the point that it could replace WxRuby, and once that was done the focus would shift to working with 2.5.x. I''d like to request that the focus of WxRuby-SWIG switch to targeting 2.5.x. Mostly this is because the Mac OS X support in 2.4.2 is so poor that I''m not even bothering with it until 2.5.x, and the thought of having to wait to support OS X for two phases of development (finishing WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite discouraging, especially since the move to WxRuby-SWIG is taking longer than originally anticipated. But I''m also thinking that, since WxWidgets has some core changes in 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to incorporate those changes. Application code will need to change to adapt to 2.5, and although WxRuby-SWIG hasn''t been expected to introduce changes of its own, this would be a perfect time to incorporate some of the planned features (e.g. label=() vs. set_label()) and only have to break existing code *once.* For those wanting to add classes to WxRuby-SWIG, I would think it would be preferable to just work on the 2.5 version, rather than adding one for 2.4 and then having to revisit it for the change to 2.5. I recognize that 2.5 is currently not regarded as the "stable" release, but for me the problems of the Mac port combined with the bugs in 2.4 (such as missing XRC support for status bars) make 2.5 much more attractive, and I''d like to move to it as soon as possible. Thoughts? Thanks very much to Nick, Kevin, Park, Curt, and the rest for this excellent project. I really appreciate the time you''ve put into it. I''m using it daily and hope to contribute in the future as I become more comfortable with how WxWidgets works, although my C++ is pretty rusty at the moment. :-) Marshall _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
I favor this as well, because I do believe that wxWidgets 2.5.x has alpha transparency...and that would be so sweet...we have a work app we do in java right now I could move to wxRuby if I could use the transparency.... I''m also a plus 1 (as Nick already knows) to help wherever and whenever I can, Zach Sean Long wrote:> I agree with Marshall. > > I have not touched wxRuby lately because I needed to move to wx 2.5.x to > fix a "chicken/egg" condition in 2.4.x printing. Another reason to move > to 2.5.x now is the changes to break-up the libs. Also wxPython is using > 2.5.3 and we can''t let that lesser language show us up ;) > > Sean > > -----Original Message----- > From: wxruby-users-bounces@rubyforge.org > [mailto:wxruby-users-bounces@rubyforge.org] On Behalf Of Marshall > Elfstrand > Sent: Friday, December 17, 2004 9:06 AM > To: General discussion of wxRuby > Subject: [Wxruby-users] WxRuby-SWIG and WxWidgets 2.5.x > > > A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don''t remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with > the thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I''d like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that > I''m not even bothering with it until 2.5.x, and the thought of having > to wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I''m also thinking that, since WxWidgets has some core changes in > 2.5 versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn''t been expected to > introduce changes of its own, this would be a perfect time to > incorporate some of the planned features (e.g. label=() vs. > set_label()) and only have to break existing code *once.* For those > wanting to add classes to WxRuby-SWIG, I would think it would be > preferable to just work on the 2.5 version, rather than adding one for > 2.4 and then having to revisit it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I''d like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you''ve put into it. > I''m using it daily and hope to contribute in the future as I become > more comfortable with how WxWidgets works, although my C++ is pretty > rusty at the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > >
I''d like to make a move too, but it''s not a "throw a switch for a solution" problem. The biggest issue is that wxruby-swig depends on a generated XML file created off the wxWidgets 2.4.2 documentation. We only have the XML file; we don''t have the script that made it. Without an XML file description of the 2.5.2, the move to 2.5.2 has to be done by hand. A good ruby project would be to generate a similar ruby script to do what was already done earlier - a script that parses the wxWidgets docs and generates an XML description of the library. The original file can be seen at: http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/wxclasses-2.4.2.xml?rev=1.1&cvsroot=wxruby&content-type=text/vnd.viewcvs-markup (try to avoid slashdotting rubyforge by not going all at once :-) I''d also like to hear what issues your having with wxruby for the Mac. I know Marshall would like XRC toolbar support, but what other issues are arising? It may be that there are more wxruby issues than wx issues. Nick Marshall Elfstrand wrote:> A while back there was a discussion about what version of WxWidgets to > target with WxRuby-SWIG. I don''t remember seeing any resolution, but I > gather that thus far WxRuby-SWIG has continued to target 2.4.2, with the > thinking that WxRuby-SWIG would quickly mature to the point that it > could replace WxRuby, and once that was done the focus would shift to > working with 2.5.x. > > I''d like to request that the focus of WxRuby-SWIG switch to targeting > 2.5.x. > > Mostly this is because the Mac OS X support in 2.4.2 is so poor that I''m > not even bothering with it until 2.5.x, and the thought of having to > wait to support OS X for two phases of development (finishing > WxRuby-SWIG/2.4 and then moving to WxRuby-SWIG/2.5) is quite > discouraging, especially since the move to WxRuby-SWIG is taking longer > than originally anticipated. > > But I''m also thinking that, since WxWidgets has some core changes in 2.5 > versus 2.4, the switch to a new WxRuby base is a perfect time to > incorporate those changes. Application code will need to change to > adapt to 2.5, and although WxRuby-SWIG hasn''t been expected to introduce > changes of its own, this would be a perfect time to incorporate some of > the planned features (e.g. label=() vs. set_label()) and only have to > break existing code *once.* For those wanting to add classes to > WxRuby-SWIG, I would think it would be preferable to just work on the > 2.5 version, rather than adding one for 2.4 and then having to revisit > it for the change to 2.5. > > I recognize that 2.5 is currently not regarded as the "stable" release, > but for me the problems of the Mac port combined with the bugs in 2.4 > (such as missing XRC support for status bars) make 2.5 much more > attractive, and I''d like to move to it as soon as possible. > > Thoughts? > > Thanks very much to Nick, Kevin, Park, Curt, and the rest for this > excellent project. I really appreciate the time you''ve put into it. > I''m using it daily and hope to contribute in the future as I become more > comfortable with how WxWidgets works, although my C++ is pretty rusty at > the moment. :-) > > Marshall > > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Nick wrote:> > I''d like to make a move too, but it''s not a "throw a switch for a > solution" problem. The biggest issue is that wxruby-swig depends on a > generated XML file created off the wxWidgets 2.4.2 documentation. We > only have the XML file; we don''t have the script that made it.Actually, we do. But it''s a complex and error-prone script, written in perl: http://www.bzzt.net/~wxwindows/index2.html> A good ruby project would be to generate a similar ruby script to do > what was already done earlier - a script that parses the wxWidgets docs > and generates an XML description of the library.An alternative that has been mentioned before would be to create a swig script that uses their parser to go through the wxWidgets C++ header files, and outputs a sanitized and simplified version of those headers, which could then be fed into the wxRuby rake build process. I find writing swig scripts challenging enough that I was happier to use the existing XML file (even though it contained errors where the docs didn''t match the actual headers). Perhaps someone else here would be less intimidated by swig and could do this. I wonder if it would be possible or worth it to support both. Gentoo doesn''t seem to have an ebuild for wxWidgets 2.5 yet.> The original file can be seen at:(snip)> (try to avoid slashdotting rubyforge by not going all at once :-)Especially since it is HUGE!!! Don''t bother looking at it unless you''re serious. It''s just an enormous XML file representing everything in the html wxWindows docs. Kevin
Nick wrote:> > A good ruby project would be to generate a similar ruby script to do > what was already done earlier - a script that parses the wxWidgets docs > and generates an XML description of the library. The original file can > be seen at: > > http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/wxclasses-2.4.2.xml?rev=1.1&cvsroot=wxruby&content-type=text/vnd.viewcvs-markup >This just parses the same docs that wxWindows has alone, into this xml format? Is there anything else added manually besides that? Zach
Nick wrote:> > I''d like to make a move too, but it''s not a "throw a switch for a > solution" problem. The biggest issue is that wxruby-swig depends on a > generated XML file created off the wxWidgets 2.4.2 documentation. We > only have the XML file; we don''t have the script that made it. Without > an XML file description of the 2.5.2, the move to 2.5.2 has to be done > by hand.To comment on my last post. If all the xml file is, is an automated file created by existing wxWindows docs, and if the format is to stay consistent with the existing XML file format (is there a dtd i can check against?), then I wouldn''t mind starting the parsing project for getting 2.5.x going... If there are any other takers who''d like to assist on a project like this, let me know and let''s try to coordinate something. If someone has already taken the liberty to start this project, please let me know so I don''t duplicate effort. If you need assistance then just hollar at me... Thanks, Zach
Zach Dennis wrote:> > Nick wrote: > > > > > I''d like to make a move too, but it''s not a "throw a switch for a > > solution" problem. The biggest issue is that wxruby-swig depends on a > > generated XML file created off the wxWidgets 2.4.2 documentation. We > > only have the XML file; we don''t have the script that made it. Without > > an XML file description of the 2.5.2, the move to 2.5.2 has to be done > > by hand. > > To comment on my last post. If all the xml file is, is an automated file > created by existing wxWindows docs, and if the format is to stay > consistent with the existing XML file format (is there a dtd i can check > against?), then I wouldn''t mind starting the parsing project for getting > 2.5.x going...I don''t think its particularly important to stay consistent with the existing format. The main thing is to get the essential information. One of the reasons why the current XML file is sometimes wrong is because it was generated from the comment blocks in the wxWidgets code. If the comment block is wrong, then the XML is wrong. The approach that Kevin described eliminates this problem by using the code itself, not the comment blocks) by parsing the output from a swig pass.> If there are any other takers who''d like to assist on a project like > this, let me know and let''s try to coordinate something. > > If someone has already taken the liberty to start this project, please > let me know so I don''t duplicate effort. If you need assistance then > just hollar at me...I think you''ve got it. I''m not aware of any one else working on this. Curt
Curt Hibbs wrote:> Zach Dennis wrote: >>To comment on my last post. If all the xml file is, is an automated file >>created by existing wxWindows docs, and if the format is to stay >>consistent with the existing XML file format (is there a dtd i can check >>against?), then I wouldn''t mind starting the parsing project for getting >>2.5.x going... > > I don''t think its particularly important to stay consistent with the > existing format. The main thing is to get the essential information.Right. The XML format could change, as long as wxruby-swig/swig/extractxml.rb is updated to handle the new format. Note that the bulk of extractxml is correcting errors in the XML file. If the XML were 100% correct, it would be a pretty small and simple tool.> The approach that Kevin described eliminates this problem by using the code > itself, not the comment blocks) by parsing the output from a swig pass.Yes. Our goal is to have clean .h files representing the wxWindows classes, that we can hand to SWIG so it can auto-generate wrappers. The XML file is just a mechanism to get there. Whether we write our own wxWidget doc extraction tool, or a swig-based extraction tool, we could bypass the XML step and directly generate simple .h files. Cheers, Kevin
Kevin Smith wrote:> Curt Hibbs wrote: > >> Zach Dennis wrote: >> >>> To comment on my last post. If all the xml file is, is an automated file >>> created by existing wxWindows docs, and if the format is to stay >>> consistent with the existing XML file format (is there a dtd i can check >>> against?), then I wouldn''t mind starting the parsing project for getting >>> 2.5.x going... >> >> >> I don''t think its particularly important to stay consistent with the >> existing format. The main thing is to get the essential information. > > > Right. The XML format could change, as long as > wxruby-swig/swig/extractxml.rb is updated to handle the new format. > Note that the bulk of extractxml is correcting errors in the XML file. > If the XML were 100% correct, it would be a pretty small and simple tool. > >> The approach that Kevin described eliminates this problem by using the >> code >> itself, not the comment blocks) by parsing the output from a swig pass. > > > Yes. Our goal is to have clean .h files representing the wxWindows > classes, that we can hand to SWIG so it can auto-generate wrappers. The > XML file is just a mechanism to get there. Whether we write our own > wxWidget doc extraction tool, or a swig-based extraction tool, we could > bypass the XML step and directly generate simple .h files.What would be the most preferred way to receive this input...generate xml first....or skip and generate .h files? Or do xml first, then go after .h files? If we go xml, then .h files route, we can work with where we are now, and improve on it. While development is still underway I can work on the .h files output, and then when that is stable/ready/tested we can switch over...what do you guys think of this? If .h files is it could I get someone to post a sample .h file so I can see in comparison, what the original wxWindows .h file looked like and what the outputted .h file I''d be generating looks like? For existing inputs and outputs, waht scripts, files, etc... do I want to be looking so i can see how the process happens now.Is is just the xml file and the extractxml.rb files? Thanks, Zach
Zach Dennis wrote:> What would be the most preferred way to receive this input...generate > xml first....or skip and generate .h files? Or do xml first, then go > after .h files?There is not a single correct answer.> If we go xml, then .h files route, we can work with where we are now, > and improve on it. While development is still underway I can work on the > .h files output, and then when that is stable/ready/tested we can switch > over...what do you guys think of this?I generally like incremental approaches that build on working code. But in this case, the XML format may be more complex than we need, and it might be much simpler for you to output .h files directly.> If .h files is it could I get someone to post a sample .h file so I can > see in comparison, what the original wxWindows .h file looked like and > what the outputted .h file I''d be generating looks like?The simplified .h files that wxruby-swig generates from XML and feeds to SWIG can be seen here: http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/classes/include/?cvsroot=wxruby It''s a bit harder to point at the complex original wxWindows .h files, because they are split by target platform, and are nested (headers including other headers). You can look in your own include/wx directory, or browse here (on a painfully slow server, it seems): http://cvs.wxwidgets.org/viewcvs.cgi/wxWindows/include/wx/ If you compare bitmap.h in each context, you will see a typical example the dramatic difference. One of my secondary goals was to create a set of .h files that were completely independent of wxruby. Such a set of .h files would help anyone trying to swig wx into another language, so they wouldn''t have to go through this same hassle to get simple, swiggable .h files. Kevin
Kevin Smith wrote:> Zach Dennis wrote: > >> What would be the most preferred way to receive this input...generate >> xml first....or skip and generate .h files? Or do xml first, then go >> after .h files? > > > There is not a single correct answer.So what you''re saying is the answer is "Yes" to all the above? =)> >> If we go xml, then .h files route, we can work with where we are now, >> and improve on it. While development is still underway I can work on >> the .h files output, and then when that is stable/ready/tested we can >> switch over...what do you guys think of this? > > > I generally like incremental approaches that build on working code. But > in this case, the XML format may be more complex than we need, and it > might be much simpler for you to output .h files directly. > >> If .h files is it could I get someone to post a sample .h file so I >> can see in comparison, what the original wxWindows .h file looked like >> and what the outputted .h file I''d be generating looks like? > > > The simplified .h files that wxruby-swig generates from XML and feeds to > SWIG can be seen here: > > http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/swig/classes/include/?cvsroot=wxruby > > > It''s a bit harder to point at the complex original wxWindows .h files, > because they are split by target platform, and are nested (headers > including other headers). You can look in your own include/wx directory, > or browse here (on a painfully slow server, it seems): > > http://cvs.wxwidgets.org/viewcvs.cgi/wxWindows/include/wx/ > > If you compare bitmap.h in each context, you will see a typical example > the dramatic difference. > > One of my secondary goals was to create a set of .h files that were > completely independent of wxruby. Such a set of .h files would help > anyone trying to swig wx into another language, so they wouldn''t have to > go through this same hassle to get simple, swiggable .h files.Ok, I will look into these this weekend and into this next week and I''ll be sure to post any questions I have. Thanks, Zach
Zach, Before you get too far into making the XML file, I have a task for you that is a bit more pressing: A new documentation script for wxruby-swig. Currently, wxruby has a documentation script that was created for the .t files. You (and others) have mentioned the output is a bit hard to use, and they constantly need to return to the C++ docs. Since the XML file has all of the C++ docs inside of it, I''d like you to get wxruby-swig from CVS and write a ruby script that extracts the XML docs for all the classes in the swig/classes directory. Now - what output format you want to use is up to you. I personally hate the HTML docs that rdoc generates (or perhaps I simply like my class/method listing on the side as opposed to the top), but if people here like rdoc then I think it should be the chosen output format. There is also doxygen and ndoc, which both have really good output formats. As far as converting to 2.5 is concerned, it may be that not all that many methods have changed underneath, and we can solve the problem with existing tools. Nick Zach Dennis wrote:> Nick wrote: > >> >> I''d like to make a move too, but it''s not a "throw a switch for a >> solution" problem. The biggest issue is that wxruby-swig depends on a >> generated XML file created off the wxWidgets 2.4.2 documentation. We >> only have the XML file; we don''t have the script that made it. Without >> an XML file description of the 2.5.2, the move to 2.5.2 has to be done >> by hand. > > > To comment on my last post. If all the xml file is, is an automated file > created by existing wxWindows docs, and if the format is to stay > consistent with the existing XML file format (is there a dtd i can check > against?), then I wouldn''t mind starting the parsing project for getting > 2.5.x going... > > If there are any other takers who''d like to assist on a project like > this, let me know and let''s try to coordinate something. > > If someone has already taken the liberty to start this project, please > let me know so I don''t duplicate effort. If you need assistance then > just hollar at me... > > Thanks, > > Zach > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > > >
Nick wrote:> > Zach, > > Before you get too far into making the XML file, I have a task for you > that is a bit more pressing: A new documentation script for wxruby-swig. > > Currently, wxruby has a documentation script that was created for the .t > files. You (and others) have mentioned the output is a bit hard to use, > and they constantly need to return to the C++ docs. > > Since the XML file has all of the C++ docs inside of it, I''d like you to > get wxruby-swig from CVS and write a ruby script that extracts the XML > docs for all the classes in the swig/classes directory. Now - what > output format you want to use is up to you. I personally hate the HTML > docs that rdoc generates (or perhaps I simply like my class/method > listing on the side as opposed to the top), but if people here like rdoc > then I think it should be the chosen output format. There is also > doxygen and ndoc, which both have really good output formats.I''ll shift gears and start getting on this. Zach