Greetings all, Over the last few months, while I have been busy on other projects, Nick and other folks have built wxruby-swig up to where it now supports about 120 classes, compared to the 139 in wxruby 0.6. When you include the fact that wxruby 0.6 had a few classes that really weren''t needed (because non-wx ruby versions work fine), it looks like wxruby-swig is actually very close to wxruby 0.6 in terms of functionality. And remember, it is actually far better in terms of memory leakage, and in the number of methods within each class that are fully supported. Great job guys!!! I had no idea so many classes were supported, since nobody had updated the README which still claimed only about 20 classes were being included. We have had an ongoing debate about what to call wxruby-swig. I now have a concrete proposal that I plan to implement soon unless someone raises objections: 1. The new swig-based library will officially be named wxruby2. This will be used as the CVS module name, the gem name, the name for any packaging (e.g. Debian, RPM), and in most documentation. The version numbers will start with 2.0.0-preX, moving to 2.0.0-rcX, and then 2.0.0 proper. Of course, our rubyforge project will remain simply ''wxruby''. 2. The actual binary will also be named wxruby2.dll/wxruby2.so, to avoid conflicting with legacy wxruby binaries. 3. The package will include a wx.rb file which will act as a naming bridge. Ruby apps that want to use wxruby2 will require ''wx'', as they currently do with wxruby-swig. wx.rb will in turn require ''wxruby2''. We really don''t want to create a ruby-specific binary named wx.dll or wx.so, but it seems needlessly painful to make our users directly require ''wxruby2'' in their apps. 4. This wx.rb file will also be a handy place to create pure ruby api sugar. Eventually, one of the ways wxruby can really be valuable is to provide an API that is more rubyish, and coding wrappers in ruby is far easier than doing so in C++. Eventually, some of those wrappers could be ported to C++ for speed, if necessary. My goal is to release a beta version of wxruby2 within a few weeks. Kevin
Kevin Smith wrote:> > My goal is to release a beta version of wxruby2 within a few weeks.Quick reminder: If you want to play around with wxruby-swig, but don''t want to deal with CVS, you can download a daily(?) snapshot tarball from this rubyforge page: http://rubyforge.org/cgi-bin/viewcvs.cgi/wxruby-swig/?cvsroot=wxruby Click on the "download tarball" link at the lower left. Kevin
Kevin, I''m really glad to see you''ve got the time and energy to jump back in to wxRuby development. You accomplished much goodness in only a few days! I like the idea of moving to a wxRuby2 name. Besides being a proper reflection of the project, I think having a 2.x version number will have a positive psychological effect on potential users. Curt Kevin Smith wrote:> Greetings all, > > Over the last few months, while I have been busy on other projects, Nick > and other folks have built wxruby-swig up to where it now supports about > 120 classes, compared to the 139 in wxruby 0.6. When you include the > fact that wxruby 0.6 had a few classes that really weren''t needed > (because non-wx ruby versions work fine), it looks like wxruby-swig is > actually very close to wxruby 0.6 in terms of functionality. And > remember, it is actually far better in terms of memory leakage, and in > the number of methods within each class that are fully supported. > > Great job guys!!! I had no idea so many classes were supported, since > nobody had updated the README which still claimed only about 20 classes > were being included. > > We have had an ongoing debate about what to call wxruby-swig. I now have > a concrete proposal that I plan to implement soon unless someone raises > objections: > > 1. The new swig-based library will officially be named wxruby2. This > will be used as the CVS module name, the gem name, the name for any > packaging (e.g. Debian, RPM), and in most documentation. The version > numbers will start with 2.0.0-preX, moving to 2.0.0-rcX, and then 2.0.0 > proper. Of course, our rubyforge project will remain simply ''wxruby''. > > 2. The actual binary will also be named wxruby2.dll/wxruby2.so, to avoid > conflicting with legacy wxruby binaries. > > 3. The package will include a wx.rb file which will act as a naming > bridge. Ruby apps that want to use wxruby2 will require ''wx'', as they > currently do with wxruby-swig. wx.rb will in turn require ''wxruby2''. We > really don''t want to create a ruby-specific binary named wx.dll or > wx.so, but it seems needlessly painful to make our users directly > require ''wxruby2'' in their apps. > > 4. This wx.rb file will also be a handy place to create pure ruby api > sugar. Eventually, one of the ways wxruby can really be valuable is to > provide an API that is more rubyish, and coding wrappers in ruby is far > easier than doing so in C++. Eventually, some of those wrappers could be > ported to C++ for speed, if necessary. > > My goal is to release a beta version of wxruby2 within a few weeks. > > Kevin > _______________________________________________ > wxruby-users mailing list > wxruby-users@rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users > >
Kevin Smith wrote:> [...] > > My goal is to release a beta version of wxruby2 within a few weeks. > > KevinKevin, Thanks so much for updating wxruby. IMHO, wxruby is one of the most important projects in ruby. With a hardcopy book on wxWidgets coming out this month, I''m sure wxWidgets will continue to grow in popularity. I''d like to see wxruby2 continue to be able to use wxWidgets 2.6.0 rather than 2.6.1 or later versions. There were some wording changes in the wxWidgets 2.6.1 license that (unintentionally according to one wxWidgets developer) requires derived binary works to allow reverse-engineering and modifications by end users. Continued support for 2.6.0 will make wxruby more compatible with commerical EULA. Thanks again!