wxRuby 1.9.2

I’m happy to announce that wxRuby 1.9.2 is now available from Rubyforge.
As usual we’ve got source and binary gems for Win32, OS X and Linux:

http://rubyforge.org/frs/?group_id=35

or

gem install wxruby

== WHAT’S NEW ==

This release has a mix of new syntax features, new classes, and lots of
minor fixes and additions

  • New shorter syntax for event handlers
  • New shorter syntax for starting apps
  • Added CollapsiblePane and CollapsiblePaneEvent
  • Added Sound class for playing simple WAV effects
  • Various method-specific fixes in GUI classes
  • New and improved samples and documentation, including threads sample

== SYNTAX CHANGES ==

All the syntax additions are backwards compatible. The main change is
that when setting up an event handler that just passes onto a method,
instead of writing:

evt_button(my_button.wx_id) { | e | on_button_click(e) }

You can just write

evt_button my_button, :on_button_click

Phew! There’s more information in the event handling tutorial in the
docs. Also, for simple apps, instead of having to create a custom
Wx::App subclass, you can run an app like this:

Wx::App.run do
f = Frame.new(nil, :title => ‘WxRuby demo’)
f.show
end

This will create an App, show a Window and start the main loop, all in
four lines of code.

== INCOMPATIBLE API CHANGES ==

TreeCtrl#get_first_child now only returns a single value, the tree id of
the relevant first child. Use #get_next_sibling to loop over a group of
child tree nodes, or use the convenience method #get_children.

== KNOWN ISSUES ==

At a late stage a minor regression has shown up. Some methods which may
return a Wx::Window or Wx::Sizer (eg Window#get_sizer) can raise a
RuntimeError instead of returning nil if nothing is set. A fix is
already in SVN, but for the time being, if you get “Cannot wrap nil as
Wx::Window” errors, simply rescue them and return nil.

== CREDITS ==

Probably more than any previous wxRuby release, this one has been driven
by user contributions: patches, suggestions and bug reports. Thanks to
Sean L., Sean Lindsay, Mario S., Christophe Bludau, Chauk-Mean P,
Dirk T., Gregor Schmidt, Bela Babik and others who’ve helped out.

September 2007 was our busiest month yet for wxRuby downloads - just shy
of 2,000. Average monthly downloads are two or three times what they
were just one year ago. So thanks all for your support & patience as the
library has matured; keep it coming!

cheers
alex

I downloaded 1.9.2 and changed to the new event handler syntax.

I’d like to try out the wxRuby Sound class in my App (replacing the
win32-sound calls that I’m using now). Where can I find documentation
on
the API?

Eric R.

Eric R. wrote:

I’d like to try out the wxRuby Sound class in my App (replacing the
win32-sound calls that I’m using now). Where can I find documentation on
the API?

It should be here, but the doc seems to have got cut off:
http://wxruby.rubyforge.org/doc/sound.html

For now, refer to the wxWidgets docs:
http://www.wxwidgets.org/manuals/stable/wx_wxsound.html

The only differences from the C++ docs are:

  1. use Wx::SOUND_ASYNC instead of wxSOUND_ASYNC etc
  2. The class (“static”) method is Wx::Sound.play_sound(‘foo.wav’,
    Wx::SOUND_ASYNC)

You don’t need to worry about destructors. I think wxWidgets only
implements new/play/play_sound/stop across all three platforms - don’t
use is_playing if you want portability

We’ll fix up some WxRuby docs for the next release. Shout if you run
into any probs

cheers
alex

Hi Jamal

Nice to hear from you. I am always impressed with the feedback I read
about TextPal - it’s a great example of wxRuby’s support for OS
accessibility features.

Jamal M. wrote:

This may be a known issue, but in case not,
gem install is not finding the Windows packages.

Yes, it’s a known issue. Changes in Rubygems broke the platform-matching
for binary gems, but we’re working with the devs to fix that.

Given the WxSugar merging, are all its syntax conveniences planned? For
example, I noticed that arrange_grid requires WxSugar at this point. I
particularly appreciate syntax that makes layout more convenient. I
noticed that sizers do not yet accept the :parameter => value style.

We haven’t really discussed merging the ‘layout’ features of wxSugar
into core. I wasn’t sure how used and useful they were, and I’ve moved
over to using XRC + DialogBlocks so I’m personally using those features
less.

But I realise it’s important to support pure editor-based programming as
well, so I’m open to tidying them up and merging them. What do others
think?

For some reason, the previous WxRuby is accessible with both the ruby.exe
and rubyw.exe interpreters, whereas WxRuby2 only is with rubyw.exe. This
makes debugging code more difficult with a screen reader. I need to run a
script with ruby.exe to get error messages printed to the console, but if
the script runs without errors, my screen reader (JAWS) shuts up
completely. Has a change been made concerning redirection of standard or
error output streams, or use of threads, when running in Windows as
opposed to console mode?
Not that I’m aware of. I almost always run under ruby.exe on Windows and
haven’t had any problems on normal exit, but I will try installing the
screen reader. Are you running from the standard windows command prompt?

When instantiating a Frame or Dialog, can the code be made to assume nil
for the parent if that parameter is not specified? In that way, one could
just use a single :title => value parameter without nil as the first
parameter preceding it.

This is a bit tricky, because we need to distinguish between a nil
parent and a call to the no-argument constructors for Frame or Dialog,
which are used in conjunction with XRC. I will see if there’s a
backwards-compatible way of assuming a nil parent if there is any
keyword argument passed.

Thanks for all the work by the WxRuby 2 developers! I found valuable
samples and wiki information that have helped me get up to speed with the
current WxRuby capabilities.
Thanks for your kind words. I see that there have been recent releases
of TextPal - is it still based on wxRuby? Please do feel free to post
news of major releases here, as I’m sure people are interested to see
examples of fully-featured end-user wxRuby applications.

cheers
alex

I hadn’t tried a beta in a while, but did earlier this week with the
latest WxRuby and WxSugar. This may be a known issue, but in case not,
gem install is not finding the Windows packages.

Given the WxSugar merging, are all its syntax conveniences planned? For
example, I noticed that arrange_grid requires WxSugar at this point. I
particularly appreciate syntax that makes layout more convenient. I
noticed that sizers do not yet accept the :parameter => value style.

For some reason, the previous WxRuby is accessible with both the
ruby.exe
and rubyw.exe interpreters, whereas WxRuby2 only is with rubyw.exe.
This
makes debugging code more difficult with a screen reader. I need to run
a
script with ruby.exe to get error messages printed to the console, but
if
the script runs without errors, my screen reader (JAWS) shuts up
completely. Has a change been made concerning redirection of standard
or
error output streams, or use of threads, when running in Windows as
opposed to console mode? I’d like to help get to the bottom of this so
that I can encourage other blind programmers to try GUI programming with
the latest WxRuby.

When instantiating a Frame or Dialog, can the code be made to assume nil
for the parent if that parameter is not specified? In that way, one
could
just use a single :title => value parameter without nil as the first
parameter preceding it.

Thanks for all the work by the WxRuby 2 developers! I found valuable
samples and wiki information that have helped me get up to speed with
the
current WxRuby capabilities.

Jamal