Hi I''m pleased to announce the release of wxruby2 version 1.9.0. This is a significant milestone for wxruby as this is the first release that we consider near to production quality. We hope that this 1.9.x series of releases will soon lead to a stable wxruby 2.0. = INSTALLATION The easiest way to install is using a ready-to-use binary gem for your platform: gem install wxruby Or download source or binaries from http://rubyforge.org/frs/?group_id=35 Important - if you''ve previously installed any of the wxruby2-preview series of gems, please uninstall these before installing 1.9.0 We hope to offer an OS X/PPC build at some point soon. = CHANGES Though there are a lot of code changes in this release, most of them dealt with internals. But though there''s not that much shiny new functionality, we hope you''ll like the improved stability, performance and integration with Ruby. * Completely overhauled the memory management system, fixing several widespread memory leaks, and crashers * Reworked the event handling system to allow user-defined event types to be written in ruby; added several missing events * Added HyperlinkCtrl * Enable custom ArtProviders to be written in Ruby * Many class-specific enhancements from the 2.8 API and bugfixes to problem methods * The usual additions and corrections to the docs and samples Full details are in the Changelog in the package. = KNOWN ISSUES There are a small number of method-specific bugs still outstanding; these are listed on the rubyforge Bug Tracker. Please add to this list and help us create a top-quality wxruby2. = DEVELOPMENT PLAN The plan is to tackle outstanding and newly-found bugs in this release and keep making 1.9.x releases until we have something we can call 2.0 Though wxruby2 doesn''t support the whole wxWidgets 2.8 API, at the moment it isn''t planned to add any more classes for 2.0. We feel the need for a stable, production-ready version of wxruby is greater than that for any particular class. But feel free to make a case for a class that you think MUST be in there, and we''re still open to receiving patches ... = CREDITS Thanks to Sean Long for numerous code fixes and enhancements, as well as much time testing and providing builds. Thanks also to bug reporters and contributors on the mailing lists. Kevin Smith, who created wxruby2 and led the project for several years recently stepped down from the wxruby dev team. He deserves massive credit for all his work; without his efforts there would almost certainly not be this release today. We wish him all the best. cheers alex
Hey Alex, Great work you guys on the 1.9.0 beta release. I think I notice a dramatic improvement in load time from the begining of execution. Before it was like a second or so, before the app would load on my computer, now it''s less then 300th of a second. Major improvement there. I found a little quirk in the way 1.9.0 works, compared to preview 0.0.40 works, and I think it''s in the way you now handle Events. After reviewing the problem, and writting an email to the list, I found the fault in my logic. Before, I was using a method named connect in my app to make a connection to a Server, when the user prompted for it. Ofcourse, this now clashes with your current setup, which now runs with the ideal of evaluating defs for evt_* methods, then hard lining connecting them to the connect() method for events. Which threw me off guard. I ended up renaming the method I was using, and it works perfectly now. I''m going to give the TreeCtrl another try, and seperate the code specifically for it, so _IF_ I run into the same problem, I have a way to show you guys what''s it is doing. Also, another plus, as I''m writting this email, there''s definatly major improvement in performance. With preview 0.0.40, I was seeing slow times for processing text, and entering it into a RichEdit ctrl, and it seem to always take a few milliseconds to display the text. Now, it''s just boom, it''s there. Love it. I''ll report back with any bugs, or quirks I find, so others will be able to see what has changed, and know what to expect. Mario Steele On Sun, 29 Jul 2007 17:25:49 -0500, Alex Fenton <alex at pressure.to> wrote:> Hi > > I''m pleased to announce the release of wxruby2 version 1.9.0. This is a > significant milestone for wxruby as this is the first release that we > consider near to production quality. We hope that this 1.9.x series of > releases will soon lead to a stable wxruby 2.0. > > = INSTALLATION > > The easiest way to install is using a ready-to-use binary gem for your > platform: > > gem install wxruby > > Or download source or binaries from http://rubyforge.org/frs/?group_id=35 > > Important - if you''ve previously installed any of the wxruby2-preview > series of gems, please uninstall these before installing 1.9.0 > > We hope to offer an OS X/PPC build at some point soon. > > = CHANGES > > Though there are a lot of code changes in this release, most of them > dealt with internals. But though there''s not that much shiny new > functionality, we hope you''ll like the improved stability, performance > and integration with Ruby. > > * Completely overhauled the memory management system, fixing several > widespread memory leaks, and crashers > * Reworked the event handling system to allow user-defined event types > to be written in ruby; added several missing events > * Added HyperlinkCtrl > * Enable custom ArtProviders to be written in Ruby > * Many class-specific enhancements from the 2.8 API and bugfixes to > problem methods > * The usual additions and corrections to the docs and samples > > Full details are in the Changelog in the package. > > = KNOWN ISSUES > > There are a small number of method-specific bugs still outstanding; > these are listed on the rubyforge Bug Tracker. Please add to this list > and help us create a top-quality wxruby2. > > = DEVELOPMENT PLAN > > The plan is to tackle outstanding and newly-found bugs in this release > and keep making 1.9.x releases until we have something we can call 2.0 > > Though wxruby2 doesn''t support the whole wxWidgets 2.8 API, at the > moment it isn''t planned to add any more classes for 2.0. We feel the > need for a stable, production-ready version of wxruby is greater than > that for any particular class. But feel free to make a case for a class > that you think MUST be in there, and we''re still open to receiving > patches ... > > = CREDITS > > Thanks to Sean Long for numerous code fixes and enhancements, as well as > much time testing and providing builds. Thanks also to bug reporters and > contributors on the mailing lists. > > Kevin Smith, who created wxruby2 and led the project for several years > recently stepped down from the wxruby dev team. He deserves massive > credit for all his work; without his efforts there would almost > certainly not be this release today. We wish him all the best. > > cheers > alex > > > > > > > _______________________________________________ > wxruby-users mailing list > wxruby-users at rubyforge.org > http://rubyforge.org/mailman/listinfo/wxruby-users-- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/
Hi Mario Mario Steele wrote:> Great work you guys on the 1.9.0 beta release.Thanks for your kind words. The quality of this release is down to patient people like yourself and other on wxruby-users reporting wrong things with the preview releases as much as to the patches Sean and I have added. So a big thank you to you and everyone else who''s pushed wxruby2 along.> I think I notice a > dramatic improvement in load time from the begining of execution. Before > it was like a second or so, before the app would load on my computer, now > it''s less then 300th of a second.Although it wasn''t a focus for this release, by sharing more code and stripping out redundant stuff, we managed to reduce the compiled lib''s size slightly whilst adding functionality. So I''m seeing a 5%ish improvement in first-shot load time, but I''d expect that anything much more radical is down to OS caching.> Ofcourse, this now clashes with your current setup, which now runs with > the ideal of evaluating defs for evt_* methods, then hard lining > connecting them to the connect() method for events. Which threw me off > guard.There is now a connect(..) method in all EvtHandler classes, as per the wxWidgets API, making custom events possible. Classes inheriting from EvtHandler, including Wx::App, shouldn''t define connect(..) but I don''t think there should be other implications.> Also, another plus, as I''m writting this email, there''s definatly major > improvement in performance. With preview 0.0.40, I was seeing slow times > for processing text, and entering it into a RichEdit ctrl, and it seem to > always take a few milliseconds to display the text.That''s really interesting - and nice - to know. As I say, performance was much less of a priority than correctness and ruby integration for this release. But it''s certainly possible that the changes to memory management and event handling are more efficient than the predecessors. all the best alex
Hey Alex, On 7/30/07, Alex Fenton <alex at pressure.to> wrote: <snip>> Although it wasn''t a focus for this release, by sharing more code and > stripping out redundant stuff, we managed to reduce the compiled lib''s > size slightly whilst adding functionality. So I''m seeing a 5%ish > improvement in first-shot load time, but I''d expect that anything much > more radical is down to OS caching.Well, I don''t know what to tell you Alex, it''s performance improved considerably. I may have to grab wxruby2-preview again, just to measure the difference between load times on these two versions, so there''s some solid stats to show. <snip>> There is now a connect(..) method in all EvtHandler classes, as per the > wxWidgets API, making custom events possible. Classes inheriting from > EvtHandler, including Wx::App, shouldn''t define connect(..) but I don''t > think there should be other implications.I don''t know, I''m using a Wx::Panel, and for some reason, it''s attempting to use connect() on my Class, not the Wx::EvtHandler.connect() call. <snip>> That''s really interesting - and nice - to know. As I say, performance > was much less of a priority than correctness and ruby integration for > this release. But it''s certainly possible that the changes to memory > management and event handling are more efficient than the predecessors.It had to make some kind of major improvement on it, cause I''m definatly seeing improvement here. all the best alex _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users -------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/wxruby-users/attachments/20070730/6fb990fb/attachment-0001.html
Mario Steele wrote:> <snip> > > There is now a connect(..) method in all EvtHandler classes, as per the > > wxWidgets API, making custom events possible. Classes inheriting from > > EvtHandler, including Wx::App, shouldn''t define connect(..) but I don''t > > think there should be other implications. > > I don''t know, I''m using a Wx::Panel, and for some reason, it''s > attempting to use connect() on my Class, not the > Wx::EvtHandler.connect() call.Sorry, I meant to say - user-defined subclasses of any EvtHandler (including subclasses of Panel) shouldn''t normally include a connect method because it''s called internally by evt_xxx methods. In theory we could make the evt_xxx methods call #connect in EvtHandler rather than the subclass (using instance_method(:connect).bind(self).call(...) ) but it would be kind of weird not to be able to override the method in Ruby, for example for debugging or tracing.> > That''s really interesting - and nice - to know. As I say, performance > > was much less of a priority than correctness and ruby integration for > > this release. But it''s certainly possible that the changes to memory > > management and event handling are more efficient than the predecessors. > > It had to make some kind of major improvement on it, cause I''m > definatly seeing improvement here.I haven''t tried the release builds on Windows yet - I''m usually developing using a debug build which are slower. But no way am I going to complain about perceptible performance improvements, even if I can''t explain them! cheers alex
Hey Alex, Just wanted to let you know, that I have started working on the TreeCtrl, and so far, it''s working greatly. It is now showing the Icons, no problems, using the same method as what I was using for ListCtrl. So that is good news. Hopefully, I''ll have something to setup soon for showing on the site as an Ruby App developed with wxRuby. ^.^ L8ers, Mario Steele P.S. Got any Instant Messenger? Like to talk with you in real time. LOL -- Using Opera''s revolutionary e-mail client: http://www.opera.com/mail/