similar to: wxruby-swig update

Good news and bad news. First he good news. wxruby-swig now compiles on Linux, Mac, and Windows using wxWidgets 2.5. I just patched a bug with the paint method today, but it''s getting very close to the first release of wxruby. With a little more cleanup, I think we''re getting ready to do a first release of it, which will hopefully replaced wxruby. Of course, the debug spew

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.

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

Greetings, I wanted to give you all a progress report on wxruby-swig, the next generation of wxruby. As most of you know, we are in the process of rewriting wxruby from scratch, using SWIG instead of the custom wxpp template tool in the current version. Using SWIG will make it easier for more people to add support for new classes and methods, and will make it easier to optimize (and fix)

REMINDER: This news is about the swig-based prototype. The main wxRuby release is still current at 0.3.0. I just pushed the latest wxruby-swig code to: http://qualitycode.com/repos/wxruby-swig Thanks to Nick for reminding me about the Window#paint method that wxRuby 0.3 supports. I had forgotten all about it. There may be other features that we manually added to wxRuby that I will need to

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

In case you missed the earlier thread, I am exploring using SWIG as part of the wxRuby build process. So far, wxruby-swig is purely experimental, and supports almost no wx classes or methods. I just pushed wxruby-swig 0.0.2 up to my public darcs repo: http://qualitycode.com/repos/wxruby-swig/ As always, you can use wget if you don''t have darcs. If you really need a tarball

Feature Requests item #17477, was opened at 2008-01-25 01:57 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=221&aid=17477&group_id=35 Category: None Group: None Status: Open Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: wxruby fails with SWIG 1.3.33 Initial Comment: Using SourceMage GNU/Linux. Stable recently upgraded to

I''ve checked a number of new .i files into the wxruby-swig tree. Not all of them are fully tested, but I thought it would be better for them to be there than to have somebody start duplicating the work. I''ve also added the ''caret'' and ''image'' samples, as well as the generic etc/test.rb. These need the unreleased SWIG-1.3.22. The current

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

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

After seeing contributions from Dmitry and Alex, I''m wondering how we can better organize and encourage user contributions. ORGANIZING Maybe identifying what is still missing in wxRuby-SWIG and publishing a prioritized todo list could useful to contributors. GETTING NOTICED It might be useful to post a link to the unassigned todo list each month to comp.lang.ruby and ask for

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

Sorry for the lameness, but I need things explained to me very slowly... -----Original Message----- Subject: RE: [Wxruby-users] wxGrid Question > > Yes, grab the latest tarball from the above location. Then, you should > install rubygems if you haven''t already: > http://rubyforge.org/projects/rubygems/ > > That should allow you to easily install rake: >

Nick wrote: > > I''m assuming you''ve installed ruby 1.8 over the Mac default? Yep, I installed 1.8 over the Debian default. I''m running Debian Linux atm, my Mac box is the next in line for me to get going. Zach > > Nick > > Zach Dennis wrote: > >> Nick wrote: >> >>> >>> What version of Swig do you have? Make sure it

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

Bugs item #15225, was opened at 2007-10-31 01:38 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=218&aid=15225&group_id=35 Category: Incorrect behavior Group: current Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Wx::Region.contains returns an opaque SWIG pointer type Initial Comment: On Windows

Patches item #9297, was opened at 2007-03-15 00:46 You can respond by visiting: http://rubyforge.org/tracker/?func=detail&atid=220&aid=9297&group_id=35 Category: None Group: None Status: Open Resolution: None Priority: 3 Submitted By: Nobody (None) Assigned to: Nobody (None) Summary: Patch to compile wxruby 0.0.39 on windows (vc2003,swig 1.3.31,wxwidgets 2.8.0) Initial Comment:

More progress on wxruby-swig. Nothing too exciting. It now support 36 classes, compared to the (apparently) 139 supported by wxRuby 0.3. A working version of the calendar sample is included. I made several changes to the sample. I have tentatively decided *not* to wrap the wxDateTime class, and instead to automatically convert to/from Ruby''s own DateTime class. My logic is that in

I have a minimal working version of a SWIG-based wxRuby that can bring up an empty Frame with a title. On my system, it crashes on exit. I suspect this is the same problem that I mentioned months ago when I first upgraded to wxWindows 2.4.2. The problem mysteriously vanished at some point, but now it is back. I fiddled with this new code for several frustrating hours, and couldn''t