Well, dang. One of the headlines in “Top Stories” section of my Google home page just told me how the women’s figure skating competition turned out. That will seriously ruin the suspense when we watch tonight.

I haven’t been keeping up with “YARV”:http://www.atdot.net/yarv/ development as well as I should, but luckily “why”:http://whytheluckystiff.net/ is doing it for me. He passes on the “news”:http://redhanded.hobix.com/inspect/yarvNoLongerAnAcronymForYouAcknowledgeTheReekOfVapors.html that Ruby veteran Minero Aoki now has Rails running on the latest release of YARV.

Rich Kilmer has just “blogged”:http://richkilmer.blogs.com/ether/2006/02/getindibaby.html about a limited, invitation-only Beta program for something called “indi“:http://www.getindi.com. It’s still a little unclear exactly what all indi encompasses, but what I can gather so far is that:

• One of the fundamental goals is to “give you your digital independence by freeing you from specific computers, operating systems and applications.”
• The software is small enough to fit on a USB thumb drive, so that you can take it with you and use on any computer. No software is installed on the host computer that your thumb drive happens to be plugged into.
• Your personal data is stored with the software (i.e. on the thumb drive) and not on InfoEther’s (or anyone else’s) remote server. Rich’s post suggests that it’s a response (at least in part) to Google’s expanding ownership and control of our online lives.
• You can synchronize personal data (such as appointments in iCal, or Address Book contacts) between indi and the native applications on your computer.
• The software is based on a lot of the technologies that InfoEther has supported for the last few years, including “Ruby”:http://www.ruby-lang.org/, Adode’s (formerly Macromedia’s) Flash and Jabber.

There’s also some talk about using indi for shopping and playing games, but that’s not of immediate interest to me. One of the reasons that I carry around a “handheld computer”:http://www.palm.com/us/products/handhelds/tx/ is this desire for “digital independence” that indi seems to promise, so I’ve added myself to the waiting list to join the Beta program.

So this is weird.

Back in late November or early December of last year, Denise mentioned that she wished someone would invent a heated mouse. Sure enough, Googling for the phrase “heated mouse” turned up several blog articles referencing a company that claimed to produce just the item she was looking for. Never one to look an obvious Christmas gift idea in the mouth, I placed an order. I was a little troubled by the ordering process, which required me to make payment using PayPal, but I went along with it because other people seemed to having orders filled with no troubles.

I placed the order on December 10, and after a few days I sent in an e-mail inquiry to ask when the item would actually be shipped. I received a quick reply that assured me (in ALL CAPS, no less) that I’d get it on or before December 24. Great!

Well, Christmas came and went with no sign of the heated mouse. Subsequent e-mails and phone calls to the seller went unanswered. I finally filed a complaint with PayPal around January 10, but they were unable to do anything about it. (Thanks, PayPal!) I chalked it up to a $59.99 life lesson and moved on.

Hearing about someone else’s recent troubles with a sale through PayPal reminded me of my problem, so I once again Googled to see if anyone has reported problems similar to mine. I was surprised to find new comments on one of the blog articles I’d seen last year, in which other shafted customers were complaining about non-delivery of their heated mice. Most surprising, however, was a comment allegedly from the fellow who was actually selling the mouse:

Ladies and Gentleman. I am Rudy Hinojosa, creator of the heated mouse. I want to publicly express my apologies for not being able to process your orders in a timely fashion. My manufacturer deal did not go through. I’m being forced to make them once again by hand. This is so frustrating. I have about 60 back orders in queue. I have stopped new orders alltogether. I will be providing refunds for those who request it. My contact information is still the same. I’m working overtime to get these orders out.

Per the last few posts, I’m thinking a lot about potential API changes for the upcoming release of “FXRuby”:http://www.fxruby.org/ 1.6.

When Jeroen began developing “FOX”:http://www.fox-toolkit.com/ way back when, most of the available C++ compilers didn’t have great support for C++ namespaces. As a result, FOX classes ended up with an “FX” prefix to avoid name clashes. That is of course of little concern to Rubyists, as the @Module@ construct provides (among other things) a way of maintaining separate namespaces for different code libraries. Despite this, the FXRuby classes followed the standard FOX naming conventions, and so we end up with the visually jarring situation that the fully-qualified name for FOX’s button class is @Fox::FXButton@.

So one of the major changes that I’m considering for FXRuby 1.6 is renaming the classes by removing the “FX” prefix from the existing class names and method names. @Fox::FXButton@ becomes @Fox::Button@, @Fox::FXLabel@ becomes @Fox::Label@, and so on. There’s no technical reason to make such a change, but it would be more aesthetically pleasing. One disadvantage of this change would be that the FOX and FXRuby class names would no longer quite match up (although it wouldn’t be much of a brain twister to convert between the two). A more significant disadvantage is that it would break a lot of existing code. This problem could probably be alleviated by using @const_missing@, e.g.

module Fox def self.constmissing(classid) name = "FX" + classid.tos if constdefined? name constget(name) else super end end end

Another change that I’m considering is switching from CamelCase method names to method names with underscores, so that @beginWaitCursor@ becomes @beginwaitcursor@. As with the proposed change for the class name, the potential for code breakage could be alleviated by the careful use of @method_missing@, with something along the lines of:

class FXObject def methodmissing(methodid, args) camelcase = methodid.tos while camelcase =~ /([^_])(.)(.*)/ camelcase = $1 + $2.upcase + $3 end if respondto? camelcase self.send(camelcase.tosym, *args) else super end end end

Note that this idea was “inspired” by Richard Dale’s work on Ruby/Qt.

Wouldn’t it be great if huge numbers of people tuned in tonight for the series finale of ??Arrested Development???

Just to follow up on my “previous post”:http://lylejohnson.name/blog/?p=130: Most who responded on the ruby-talk list liked the proposed API change for FXRuby. “Dan Berger”:http://www.livejournal.com/users/djberg96/ noted that I should be sure to make it so that strings could be used in place of symbols, e.g.

splitter.expand("topleft", "topright")

should be equivalent to:

splitter.expand(:topleft, :topright)

Ara Howard added that accepting string values as inputs could make it easier to configure a widget via “YAML”:http://yaml4r.sourceforge.net/. For example, suppose that all widgets had a @configure@ method that took a hash:

splitter.configure({ "expand" => ["topleft", "topright"], "foo" => "bar" })

Now if you had a file @config.yml@ containing the YAML representation of that hash:

--- expand: - topleft - topright foo: bar

You could then configure the widget in one line using:

splitter.configure(YAML::load(IO::read('config.yml')))

Now, I said that most folks like the proposed changes. Simon Kröger is (so far) the lone dissenter, and he didn’t see all that much that was wrong with the current approach. He did propose an alternative approach that involved treating the attribute (here, @FX4Splitter#expanded@) as a @Symbol@ but also delegating some of the work to a @Set@. It seemed a little convoluted for my taste but it’s good to see other ways to think about the problem.

There are some things that I’m thinking of doing in “FXRuby”:http://www.fxruby.org/ 1.6 to make the API more Ruby-like. Something that I’ve been wanting to clean up for a while now is the widespread use of bit-flags for various widget attributes. This pattern shows up in a number of places in the code. For example, in “FOX”:http://www.fox-toolkit.com/ 1.6 the FX4Splitter window can be configured to expand only its top-left pane:

splitter->setExpanded(FX4Splitter::ExpandTopLeft);

or to expand both the top left and top right panes:

splitter->setExpanded(FX4Splitter::ExpandTopLeft | FX4Splitter::ExpandTopRight);

Likewise, if you want to check to see whether the bottom left pane is expanded or not, you’d write something like:

if (splitter->getExpanded() & FX4Splitter::ExpandBottomLeft) { // Bottom left pane is expanded }

Now, what I’m thinking of doing is replacing the symbolic constants like ExpandTopLeft and ExpandBottomRight with Ruby symbols, and doing something like this instead:

splitter.expand :topleft # expand top left pane splitter.expand :topleft, :top_right # expand both top left and top right panes

if splitter.expanded? :bottom_left
  # Bottom left pane is expanded
end</code>