Greetings all, The recent ruby-talk posting about wx (cross-posted here by Curt) made it clear that we need to release some code soon, to present a public image of moving forward. Thus, my first goal is to release a "preview" version of wxruby2 as soon as we have a version that builds and can run the minimal sample on all three major platforms (Linux, MS Win, Mac OSX). This would include binaries for Windows and Mac, and I would LOVE it if we could have it available in gem form and/or as RPMs or DEBs for Linux distros. Volunteers? After that, I plan to focus on unicode support and memory management. It would be great if other folks could work on adding support for more classes (and any important missing methods), and especially on improving our samples. I still hope we can do a wxruby2 1.0 release within the next couple months, but it will require help from you. Thanks, Kevin
Hi Kevin,> Thus, my first goal is to release a "preview" version of wxruby2 as soon > as we have a version that builds and can run the minimal sample on all > three major platforms (Linux, MS Win, Mac OSX). This would include > binaries for Windows and Mac, and I would LOVE it if we could have it > available in gem form and/or as RPMs or DEBs for Linux distros. Volunteers?Would it be too much to run all the samples included in the first release? In the past weeks there were moments when at least half of them ran fine on linux. But if you say making them work right needs some serious work then so be it :) I volunteer for the .deb. I''ll be offline next week though Jani
Jani Monoses wrote:> > Would it be too much to run all the samples included in the first > release? In the past weeks there were moments when at least half of > them ran fine on linux. But if you say making them work right needs > some serious work then so be it :)I''m not sure if I can resolve all memory problems that quickly, but you are probably right that it should run all of the samples that are included in the package itself (not all the samples from wxruby1). Ok. that''s the real goal for the wxruby2 preview release: Run all the samples currently in the wxruby2 tree. Segfaults after choosing exit are not showstoppers. Also, if anyone submits better-written samples to replace any of the existing wxruby2 samples, that would be great.> I volunteer for the .deb. I''ll be offline next week thoughGreat. Thanks! Kevin
Hi all Congrats to all on the progress so far, and thanks Kevin for leading this. Sounds like there''s been major replumbing going on.> Thus, my first goal is to release a "preview" version of wxruby2 as > soon as we have a version that builds and can run the minimal sample > on all three major platforms (Linux, MS Win, Mac OSX). This would > include binaries for Windows and Mac, and I would LOVE it if we could > have it available in gem form and/or as RPMs or DEBs for Linux > distros. Volunteers?Count me in for doing a source gem (will also try a mswin32 binary one if someone compiles a .so, and will try a osx). Does anyone know how to make a OS X .dmg? I think Nick had a way of doing this but I''m not sure if it is documented somewhere?> After that, I plan to focus on unicode support and memory management. > It would be great if other folks could work on adding support for more > classes (and any important missing methods), and especially on > improving our samples.Plan to do some work on the samples. Apart from 1) # better commenting 2) removingCamelCaseMethodNames and 3) formatting line-wraps etc that is needed everywhere to put the samples in exemplary ruby style? cheers alex
Alex Fenton wrote:> > Count me in for doing a source gem (will also try a mswin32 binary one > if someone compiles a .so, and will try a osx).Excellent.> Does anyone know how to make a OS X .dmg? I think Nick had a way of > doing this but I''m not sure if it is documented somewhere?Hm. I never understood that whole situation, and I don''t think any tools or docs ever got checked into the wxruby tree. Does this message help? http://rubyforge.org/pipermail/wxruby-users/2004-December/001065.html Other potentially helpful messages: http://rubyforge.org/pipermail/wxruby-users/2005-February/001171.html http://rubyforge.org/pipermail/wxruby-users/2004-October/000968.html> Plan to do some work on the samples. Apart from 1) # better commenting > 2) removingCamelCaseMethodNames and 3) formatting line-wraps etc that is > needed everywhere to put the samples in exemplary ruby style?My own preference is to not ''include Wx'' at the top of the file, since it pollutes the "global" namespace. One proposed compromise, to avoid having to use Wx:: everywhere, is to put ''include Wx'' immediately inside any Wx-related class. So minimal.rb would have: class MyFrame < Wx::Frame include Wx def initialize.... ... class MyApp < Wx::App include Wx ... My main gripe about the samples is that it''s not clear just by running them exactly what they do. Many have hidden features and obscure side effects if you do THIS before THAT instead of the other way around. To fully exercise each sample takes a lot of manual clicking. I suppose what I really want is a set of unit tests that automatically exercise all the different features of each wrapped class, but that''s not the purpose of the samples. The samples should avoid declaring explicit window ID constants wherever possible. It''s usually better to create the window with -1 as an id, and then call a method to obtain the id that was assigned. Thanks, Kevin
I completely agree on the samples being somewhat opaque. I also agree about the test cases. I am really a big advocate of the whole test-first methodology (even though I haven''t been applying it here ;) ). Regardless of whether we retool the samples as test cases or not I think we should expand the test directory. I suppose focusing on what is important to convey to new users is the most important thing. Having said that... I''m not sure where to start. The dialogs sample is probably a good one to hack apart. Roy Kevin Smith wrote:>> Plan to do some work on the samples. Apart from 1) # better >> commenting 2) removingCamelCaseMethodNames and 3) formatting >> line-wraps etc that is needed everywhere to put the samples in >> exemplary ruby style? > > > My own preference is to not ''include Wx'' at the top of the file, since > it pollutes the "global" namespace. One proposed compromise, to avoid > having to use Wx:: everywhere, is to put ''include Wx'' immediately > inside any Wx-related class. So minimal.rb would have: > > class MyFrame < Wx::Frame > include Wx > def initialize.... > ... > class MyApp < Wx::App > include Wx > ... > > My main gripe about the samples is that it''s not clear just by running > them exactly what they do. Many have hidden features and obscure side > effects if you do THIS before THAT instead of the other way around. > > To fully exercise each sample takes a lot of manual clicking. I > suppose what I really want is a set of unit tests that automatically > exercise all the different features of each wrapped class, but that''s > not the purpose of the samples. > > The samples should avoid declaring explicit window ID constants > wherever possible. It''s usually better to create the window with -1 as > an id, and then call a method to obtain the id that was assigned.