It is with mixed feelings that I announce that I’m stepping away from FXRuby development, effective immediately. I will no longer be accepting bug reports, support requests, feature requests, or general emails related to FXRuby. I will continue to follow the mailing list, but I am no longer the maintainer of this project.

When I started developing FXRuby back in late 2000, it was a lot of fun for me. I was still new to Ruby (most of us were, back then) and Ruby was in need of a good GUI toolkit, so working on FXRuby provided me with not only a good way to learn the ins and outs of the language, but also to get really plugged into the community. In recent years, however, working on FXRuby has become a chore. I’m a decade older, at a different place in my life and career, and there are frankly just too many other things that I’d rather be working on at this point. These feelings are compounded by the fact that FOX development has, as best I can tell, stalled out, and without anything new to look forward to on the FOX front there’s little motivation for me to continue working on FXRuby. So it’s time to make a clean break and call it quits.

I would like to take this opportunity to thank everyone who did participate in the FXRuby community over the years. Knowing that you found my work of some value means a lot to me, and I appreciate the encouragement that I received from you along the way. I was never successful at organizing a development team around FXRuby, something which I regret, but a number of people contributed patches or third-party tools and extensions to FXRuby. If I tried to name all of those contributors, I would invariably leave someone off the list by accident, so let me just say: Thanks, you guys; you know who you are. A special thanks as well to those of you who bought the book. And of course, I owe an immense debt of gratitude to Jeroen van der Zijp, without whom there would be no FOX toolkit, and thus no FXRuby.

Someone on the mailing list asked whether FOX and FXRuby are “pretty much dead.” I can’t speak for Jeroen or the FOX project. As for FXRuby, however, that’s up to you. FXRuby is, and always has been, an open source project. If you are interested in hacking on FXRuby, or even taking over maintenance of the project, please feel free to fork the project on GitHub and release updates as you see fit. The Wiki has a lot of information about setting up a development and build environment on Windows, Linux and Mac OS X, and if you have specific questions about the build chain I’ll do my best to help you get set up.

If no one steps forward to maintain FXRuby, that’s fine too. The code has been pretty stable, if not bug-free, for quite awhile now, and it may the case that the code’s “done” anyways. If you feel that way and want to continue using FXRuby, it’s not going anywhere. If on the other hand, you have some fresh new ideas about how to move ahead, go for it! I will be cheering you on from the sidelines.

In closing, thanks again for all of your support over the last ten years. I’m certainly not done with Ruby, and I’m looking forward to exploring other ways in which I can participate in the Ruby community in the future.

Buried a few paragraphs down in the news, however, is this tidbit:

So, what does this mean for RubyForge? The Ruby-specific functionality and data will be moved into RubyGems.org, and the parts that other hosting sites (GitHub, Google Code, SourceForge) can do better will be pruned away.

In the comments, I asked for clarification on exactly what RubyForge services will be going away, and Tom Copeland’s reply seems to indicate (to me) that the answer is “everything”:

… We’re putting together a schedule for standing down (or making read-only) various bits of RubyForge. The thing is that now there are much better options for hosting code/forums/lists/files/etc, so that stuff is going to be retired. I think back in 2003 it made sense for the Ruby community to have a dedicated site for hosting that stuff. Now I don’t think it does… I think GitHub/Google Code/SourceForge can all do a better job at that, and Ruby Central doesn’t have to expend resources/time/money supporting functionality that others are doing better.

This is troubling to me since several FXRuby-related services (such as the web page hosting, bug tracker, and mailing lists) are handled by RubyForge, and have been for a long time now. For me, it’s not merely a question of, say, finding a new place to host the mailing lists. It’s also making a decision about what to do with the archives, and dealing with all of the non-readers who will go out their way to try to subscribe to the old lists even when they’re clearly marked as inactive and then send e-mails to me to ask why that’s so. But I know that Tom and company are sensitive to these concerns, and we’ll figure out a way to make the transition work as painlessly as possible, so I’m going to try not to be a grumpy old man about it.

So in the meantime, I’m beginning to consider what my post-RubyForge options are. Setting up a dedicated Redmine installation, as Jim Weirich has done for his projects, is an attractive option as it provides one-stop shopping (and I’ve had some experience with setting up Redmine for other projects already). Another option is to go with different sites targeted at the different services, like entp’s Lighthouse for bug tracking, maybe Google Groups for the mailing list hosting, and maybe piggybacking the static web site content off of my personal web site somehow (ugh). What about you, dear reader? If you’re hosting one of the 8,500 projects at RubyForge, what plans are you contemplating for RubyForge’s looming retirement?

One of those platforms is the new MinGW-based Ruby installer for Windows, which is quickly approaching its first release candidate. This is a really exciting development and while it’s not quite yet the official Ruby distribution on Windows, I don’t think that day is far off.

I actually quietly released a MinGW-compatible gem for FXRuby 1.6.19 a month or so ago, but there’s a little problem with it, which is that it’s only compatible with Ruby 1.8.6. If you’re running the MinGW build of Ruby 1.9.1, this gem isn’t going to work for you. That’s not a problem in and of itself, but it is a problem because the RubyGems installation process has no built-in smarts to distinguish between gems that only work with one Ruby version or another. Before someone jumps on that: Yes, I’m aware of the requiredrubyversion attribute for the gem specification. What I mean is, there’s no way to say, “I want to install the FXRuby gem for my platform, but make sure you get the one that was compiled for Ruby 1.9.1 and not the one compiled for Ruby 1.8.6.” The requiredrubyversion attribute seems to only be used to prevent you from installing an incompatible gem–it’s not something that the gems are indexed on.

The recommendation from Luis Lavena of the RubyInstaller project is to build what he calls a “fat” gem (as described here and here), one that includes multiple builds of FXRuby and that selects the “right” one at load time. This will naturally increase the gem’s size, but hey, disk space is cheap and it’s a proven solution to the problem. So I’m looking into this approach now and hope to incorporate it into my build process soon.

Another new platform is Mac OS 10.6 (aka Snow Leopard). For an operating system that’s just a little over a month old, you’d be surprised at how many people are already looking for an FXRuby gem for Snow Leopard. (Well, maybe I shouldn’t be surprised, given the Mac love in the Ruby community). This has been a little tricky because some of the tricks that I’d used in the past to build universal binaries on OS 10.5 (Leopard) didn’t work quite the same way under 10.6, but I think I’ve just solved that. If you’d like to help me test this, you can download a pre-release version of that gem here. Note that this is intended for use that the Ruby 1.8.7 that comes pre-installed with Snow Leopard. If you’ve built your own Ruby (as many folks do), this might work for you too, but if it does that’s just a nice bonus.

Once I’ve resolved the problems involved in supporting these two platforms, I’m planning to release FXRuby version 1.6.20. There won’t be that many functional improvements for those of you already using FXRuby 1.6.19, but it will help to prove out the new build process and re-stabilize things for future releases. I’ve also been doing a lot of work behind the scenes recently (since the move to GitHub) to make it easier for people to hack on FXRuby and contribute code back to the project, but that’s a subject for another post.

The first step is to download and install the latest Exerb distribution (version 4.2.0, as of this writing). It’s packaged as a ZIP file, which you’ll need to extract into some convenient place on your hard drive. Once that’s done, change directories into the exerb-4.2.0 directory and run the setup.rb script.

Now, to actually go through the process of building a standalone FXRuby application, let’s start with a simple example. We’ll use the hello.rb example program from the FXRuby source code distribution. The first step is to generate a “recipe” file for your Ruby application, which is basically a listing of all the files that Exerb should use to build the executable. You’ll use the mkexy tool to do this.

ruby -r exerb/mkexy hello.rb

The mkexy tool runs your application in a custom version of Ruby to analyze which libraries it requires while it’s running. Once you exit the application, mkexy spits out a recipe file (for this example, hello.exy) in the current working directory.

Now that you have a recipe, you’re ready to run Exerb to generate the executable.

exerb hello.exy

Note that the executable that Exerb creates is quite large, as it bundles both a copy of the Ruby interpreter as well as the FXRuby library code. When I did this experiment, the executable weighed in at close to 9 Mb. You can distribute this executable to other people who don’t have Ruby or FXRuby installed on their computers.

Now let’s look at a slightly more complicated example, the hello2.rb program. The complication is that this example uses an external file, a PNG icon that it loads from disk at runtime, as shown in this excerpt:

This is unfortunately something that Exerb doesn’t handle very well, but there is a workaround. What we must first do is dump the contents of the PNG icon to a Ruby string, and store the contents in a regular .rb file. Here’s some code to do that:

Now we need to modify the bit in hello2.rb that loads the icon data, so that it instead loads this Ruby code instead:

Now, run the mkexy tool as before to generate a recipe file (hello2.exy) and then exerb to generate the executable.

ruby -r exerb/mkexy hello2.rb exerb hello2.exy

There are at least a couple of other tools out there for building standalone Ruby applications, including Erik Veenstra’s RubyScript2Exe and Jeremy Hinegardner’s Crate. I’m not at all familiar with how those tools work, but if you’ve had luck building standalone FXRuby applications with either of these tools, I’d love to hear about your experience.

You kept asking for it and so here it is – the new short, intensive, online course that helps you create UI’s using FXRuby and with YAML and ActiveRecord (with Migrations) helps you access a database.

As is often the case with machine translation, the results were more humorous than enlightening. The closing line of the first entry translates as:

Seems too long, put another log on the open bar.

The structure is so clear, I think if that is what MFC of the poor children who will have to see after that what the MFC threw it easy.

$ sudo gem install gchartrb

def bar_chart
  GoogleChart::BarChart.new('600x200', 'My Chart', :vertical) do |bc|
    bc.data 'Trend 1', [5,4,3,1,3,5], '0000ff'
    bc.data 'Trend 2', [1,2,3,4,5,6], 'ff0000'
    bc.data 'Trend 3', [6,5,4,4,5,6], '00ff00'
  end
end

The toescapedurl method for the BarChart object returns a URL from which we can retrieve the chart image data in PNG format. We can in turn use that data to construct an FXPNGImage, and place it inside an FXImageFrame:

FXImageFrame.new(self, nil, :opts => LAYOUT_FILL) do |f|
  f.image = FXPNGImage.new(app, open(bar_chart.to_escaped_url, "rb").read)
end

The result is a nice little bar chart, as shown here:

• Peter Cooper reviewed the book for the popular Ruby Inside blog, saying “Windows and Linux Ruby developers could find FOX, FXRuby and this book an excellent path into developing GUI applications with Ruby.”
• Werner Schuster of InfoQ interviewed me about FOX, and the implementation of FXRuby. This article includes a special exclusive chapter from the new book.
• Jesper de Jong reviewed the book and gave it 8 out of 10 horseshoes, writing “I like the way the book is set up; if you’re new to FXRuby, like I was when I started reading the book, then the first part is a nice and easy tutorial, and the second part is a good reference to most of FXRuby’s features if you’re using it in your own applications. So the book is useful for beginners and experienced users alike.”

If you’re interested in reviewing the book for your web site, blog, podcast, newsletter or public access television show, please let me know!