similar to: SWIG update

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

Grabbed 0.0.16 and tried a build for kicks. ...all good, except for a warning in MenuBar.cpp, then... g++ -c -I/usr/local/lib/wx/include/mac-2.4 -D__WXMAC__ -DWXMAKINGDLL -D_FILE_OFFSET_BITS=64 -D_LARGE_FILES -fno-common -fno-common -pipe -fno-common -x objective-c++ -I /usr/local/lib/ruby/gems/1.8/rake-0.3.2/lib -I /usr/local/lib/ruby/site_ruby/1.8 -I

Wow. Look what SWIG does to GetTextExtent in Grid.cpp: void SwigDirector_wxGrid::GetTextExtent(wxString const &string, int *x, int *y, int *descent, int *externalLeading, wxFont const *font) const { ... if (swig_get_up()) { wxWindow::GetTextExtent(string,x,y,descent,externalLeading,font); return; } obj0 = rb_str_new2((const char *)(&string)->mb_str());

0.0.5 sure gets the Mac build a lot further. There''s a bug in the wxMac-2.4.2 distribution that I''m running into: wx-config wants to invoke a program in the source directory at link time. That''s ugly in itself, but it tries to use a variable ${top_srcdir} to accomplish this, and it''s apparently empty. It tries to invoke

Any chance of incrementing the ol'' version number a bit more aggressively? Doing so could really help wxRuby adoption if done right: http://fishbowl.pastiche.org/2003/07/28/version_numbers_and_you -- Ryan "John" Platte Custom services, NIKA Consulting http://nikaconsulting.com/

Hi everyone, As Kevin has just announced, wxruby-swig has been moved into CVS as a toplevel project. It still is not in a "releasable" form yet, but it now builds on more systems than it doesn''t, and is moving towards stability. Because of the complexity of the build environment, we''re using rake (http://rake.rubyforge.org) as a build system instead of the standard

This fixes the wxRED Mac link error. Thanks to Nick for pointing out that I hadn''t removed some wxRED code related to an earlier experiment. Hopefully this one will build on Mac, end-to-end. I also found and fixed a problem that was causing the crash on exit: wxWindows automatically deletes the C++ app object as soon as the last frame is closed. Later, when ruby garbage collected the

SWIG 1.3.29 isn''t going to cut it for us. We''ll have to wait until 1.3.30, unless I can hack together a nasty workaround for a problem with the object tracking. It seem that each SWIG module gets its own hash for tracking objects. This means that, for example, you create a find dialog (in FindReplaceDialog.cpp) events you get from it (from FindDialogEvent.cpp)

Roy Sutton wrote (on the FreeRIDE list): > Really? That''s interesting. I haven''t checked out WxRuby but I would > be much happier using something that interfaces to the underlying > operating system''s widgets. As a member (and former leader) of the wxruby team, I thought I would share the state of the wxruby world. The current release is 0.6, and it has

Hey everybody, I''ve made some progress on wxruby-swig, and have some good news and some bad news. The good news is that the MSVC version finally can run all of the samples provided in CVS. I''m using the same solve-by-ignore solution to the GC problem that wxruby uses, so there is far less crashing goin'' on. Depending on the next few weeks, we might be able to

This one includes the latest App.cpp which includes the Mac fix from Nick. I thought it was in 0.0.11, but it wasn''t. It also adds support for "stock objects", like colours, pens, and fonts. This turned out to be quite challenging, but I''m happy with the solution. It only took a few days :-/ Kevin

I just re-integrated fixdeleting.rb, the last of the post-processors. Running minimal.rb no longer segfaults on exit. Running dialogs.rb and immediately exiting doesn''t segfault, but bringing up a dialog and then exiting does. So there are still memory problems, but fewer than yesterday :-/ I''m not sure how it compares to last week. I probably won''t have much time

In trying to add wxTextCtrl to wxruby-swig, I''ve been running into a problem with the argument conversion that appears to be a SWIG director bug. It is tied to multiple inheritance, and is related to SWIG specifically making director''s ''initialize'' take a first argument, but because ''initialize'' is static there isn''t a self value

A few days ago, someone asked me why I am using wxpp instead of SWIG. The question prompted me to revisit and re-evaluate SWIG, and I now believe it would be best to convert wxRuby to SWIG. SWIG has greatly improved its C++ support since the last time I looked at it, and I think its Ruby support has improved quite a bit as well. Also, now that I have written wxpp, I understand the nature of

Hi, in my path of getting the controls sample to work nicely, I fixed some classes on the way, see the attached diffs. I had some difficulties, but could track down all stupid bugs and am now almost happy with the code :) (I had the complete ImageHandler hieracy implemented at some time, but than I discovered the error was not in unloaded ImageHandlers but in the controls-program which does not

Hi all, I spent about 8 more hours tonight, and I think I''m close to having a wxruby2 build that works with wxWidgets 2.6.3 and SWIG 1.3.29. It should run bigdemo as well as the other samples. Unfortunately, I probably won''t have much time to work on it until next weekend :-( Tonight''s frustration was with wxART_INFORMATION. It''s sort of a wxArtID and sort of

Has anybody tried the new wxruby-swig from the msvc++ command line compiler using ''rake''? The rakefile seems to depend on the wx_config method, which doesn''t exist for msw because it doesn''t have BASH to execute the shell script. Has anyone hacked the rakefile to fix this? Nick

I just pushed a new wxruby-swig, which includes the known MSWin rakefile changes. It also has some significant internal improvements that will make it easier to add classes, and it includes support for one new class (wxEvent). wxruby-swig is now licensed under the "MIT license". wxRuby will remain under the wxWindows license as long as we are releasing the old code base. When we

I couldn''t find the original tex document that the author of the xml file converted from. Anyone knows where it is? I am toying with the idea of _not using_ the xml file. Either getting the wx header files thru SWIG (I assume you guys have thought about this before already, any specific problems?), or continue with the template generator in the current wxruby-4.0. The RUBY port of

Was trying to understand more about the internals of wxruby-swig, where does the big chunk of XML comes from? I saw something similiar in Python, is that massaged out of there? The codes produced by extractxml.rb and wxclasses-2.4.2.xml is quite different from the original header files. Just for example the WxDialog class. OnXXX are non-virtual in WxWidgets, but virtual in wxruby-swig