REMINDER: wxruby-swig is an experimental rewrite of wxRuby, using SWIG. It is not yet useful. The official wxRuby is still at 0.2.1. The 0.0.3 release of wxruby-swig is able to run the "minimal.rb" sample, which includes menu event handling. As always, it is available at: http://qualitycode.com/repos/wxruby-swig/ I also created a tarball this time, so you can just download that and have everything you need to try to build wxruby-swig. Although it has been a frustrating journey at times, I think I am ready to commit to switching wxRuby over to SWIG. I am pretty confident that I''ll be able to work around any SWIG oddities or limitations I encounter. The benefits of SWIG seem compelling. Interestingly, SWIG would not have been a great choice when wxRuby was launched. Back then, it lacked important features for creating Ruby bindings for C++ libraries. Even six months ago, it would have been painful. Many thanks to Lyle Johnson for his SWIG/Ruby work! Before wxRuby can officially switch to being SWIG-based, here are the major tasks I see remaining to be done: 1. I would like to release official wxRuby 0.3, which will be the last non-SWIG version. It has a few nice fixes and enhancements over 0.2. This could happen this week, if our binary builders are available (Curt? Nick?) 2. wxruby-swig needs to build and run on MS Windows and Mac OS X. Since I don''t have either of those platforms, I will rely on other folks to test and report problems. It seems that nobody has been brave enough yet to try building wxruby-swig. I hope that will change soon. Hint, hint :-) 3. wxruby-swig needs to support all the classes and methods that the existing wxRuby supports, before we can switch. The good news is that it is slightly easier to add support for most of them in SWIG than it was in wxpp. The bad news is that I still haven''t found a way to generate the templates automatically. Gergely created a script that scrapes method prototypes out of the wxWidgets help files. It works pretty well, but only about 90%. I haven''t yet researched how hard it would be to do something better. I would love to reuse wx/SWIG files from other projects. However, wxPython appears to use highly-customized swig files. So far I have not seen any that would be usable in wxRuby without a ton of work. That also seems to be true of wxPerl, wxBasic, wxLua, and the other seven bindings for various languages. One of my design goals is to end up with a set of class declarations that could be used by a new wx/SWIG project without much effort. That''s all for now. If you have any ideas for how we can obtain or generate swig files for all the classes, please let me know. If you try building wxruby-swig on your system, please let me know. Thanks, Kevin
Kevin Smith wrote:> > 1. I would like to release official wxRuby 0.3, which will be the last > non-SWIG version. It has a few nice fixes and enhancements over 0.2. > This could happen this week, if our binary builders are available (Curt? > Nick?)No problem, let me know when CVS is ready for me to do a 0.3 checkout and build. Curt
Kevin Smith wrote:> If you have any ideas for how we can obtain or > generate swig files for all the classes, please let me know.Great news! I was browsing the wxWidgets site, and found a link to this page: http://www.bzzt.net/~wxwindows/index2.html It offers a clean xml representation of the wxWidgets class hierarchy. It should be easy to write some Ruby code that extracts basic SWIG class declarations from it. We might also be able to use it as a starting point to generate wxRuby-specific documentation. We could auto-rename the classes and methods, and then just add special cases for the places where the API actually changes (such as passing just a Ruby array instead of an int plus C array). Kevin
Kevin Smith wrote:> > Kevin Smith wrote: > > If you have any ideas for how we can obtain or > > generate swig files for all the classes, please let me know. > > Great news! I was browsing the wxWidgets site, and found a link to this > page: > http://www.bzzt.net/~wxwindows/index2.html > > It offers a clean xml representation of the wxWidgets class hierarchy. > It should be easy to write some Ruby code that extracts basic SWIG class > declarations from it. > > We might also be able to use it as a starting point to generate > wxRuby-specific documentation. We could auto-rename the classes and > methods, and then just add special cases for the places where the API > actually changes (such as passing just a Ruby array instead of an int > plus C array).Yes... this is very cool! Curt
No problem with the new build. Does this support the new memory management stuff, or will that be in the swig version? Nick Note to Kurt: The first version of this note I sent will bounce - don''t repost. Kevin Smith wrote:> REMINDER: wxruby-swig is an experimental rewrite of wxRuby, using > SWIG. It is not yet useful. The official wxRuby is still at 0.2.1. > > The 0.0.3 release of wxruby-swig is able to run the "minimal.rb" sample, > which includes menu event handling. As always, it is available at: > http://qualitycode.com/repos/wxruby-swig/ > > I also created a tarball this time, so you can just download that and > have everything you need to try to build wxruby-swig. > > > > Although it has been a frustrating journey at times, I think I am > ready to commit to switching wxRuby over to SWIG. I am pretty > confident that I''ll be able to work around any SWIG oddities or > limitations I encounter. The benefits of SWIG seem compelling. > > Interestingly, SWIG would not have been a great choice when wxRuby was > launched. Back then, it lacked important features for creating Ruby > bindings for C++ libraries. Even six months ago, it would have been > painful. Many thanks to Lyle Johnson for his SWIG/Ruby work! > > > > Before wxRuby can officially switch to being SWIG-based, here are the > major tasks I see remaining to be done: > > 1. I would like to release official wxRuby 0.3, which will be the last > non-SWIG version. It has a few nice fixes and enhancements over 0.2. > This could happen this week, if our binary builders are available > (Curt? Nick?) > > 2. wxruby-swig needs to build and run on MS Windows and Mac OS X. > Since I don''t have either of those platforms, I will rely on other > folks to test and report problems. It seems that nobody has been brave > enough yet to try building wxruby-swig. I hope that will change soon. > Hint, hint :-) > > 3. wxruby-swig needs to support all the classes and methods that the > existing wxRuby supports, before we can switch. The good news is that > it is slightly easier to add support for most of them in SWIG than it > was in wxpp. The bad news is that I still haven''t found a way to > generate the templates automatically. > > Gergely created a script that scrapes method prototypes out of the > wxWidgets help files. It works pretty well, but only about 90%. I > haven''t yet researched how hard it would be to do something better. > > I would love to reuse wx/SWIG files from other projects. However, > wxPython appears to use highly-customized swig files. So far I have > not seen any that would be usable in wxRuby without a ton of work. > That also seems to be true of wxPerl, wxBasic, wxLua, and the other > seven bindings for various languages. One of my design goals is to end > up with a set of class declarations that could be used by a new > wx/SWIG project without much effort. > > That''s all for now. If you have any ideas for how we can obtain or > generate swig files for all the classes, please let me know. If you > try building wxruby-swig on your system, please let me know. > > Thanks, > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > >
Nick wrote:> No problem with the new build. Does this support the new memory > management stuff, or will that be in the swig version?wxRuby 0.3 will not include better memory management. Adding it would require adding code to every single class, which would be painful now, but will be trivial after all the classes are built from templates (whether from wxpp templates or swig templates). The initial official wxruby-swig (0.5?) probably won''t have proper memory management either, unless it comes along with swig for free. But the release after that (0.6?) should. Kevin