Archive for December, 2007

Tiger Butt!

Thursday, December 6th, 2007
Tiger Butt

I took this picture on our recent adventure to the San Francisco Zoo. It has sense been sync’d to our Apple TV to join a couple of hundred other random family photos.

Whenever the image passes by in slide show mode, one of us will yell “What? What?”…

… and then someone else, usually Roger, will answer “Tiger Butt!”.

Seemed to be a perfect bit of high culture to capture in ICanHasCheezBurger’s lolcat builder.

Update: Of course, the stupid lolcat builder doesn’t actually preserve stuff forever. No surprise, really. You get what you pay for.

PyObjC Xcode Templates now in Subversion

Monday, December 3rd, 2007

Ronald and I realized that the Xcode templates that are included in Leopard didn’t make it into the PyObjC repository.

So, I moved ’em over.

You can find them in the PyObjC subversion repository.

These aren’t just templates, though. See the README.txt.

As it implies, the project-tool.py script is used to effectively convert between Xcode templates and buildable projects. That is, you can create a project that builds/runs like a regular Xcode project, and then easily turn it into a template with the invocation of a simple command line like this:

project-tool.py -k -v --template Cocoa-Python\ Document-based\ Application/CocoaDocApp.xcodeproj/TemplateInfo.plist \
    Cocoa-Python\ Document-based\ Application/ \
    ~/Library/Application\ Support/Developer/Shared/Xcode/Project\ Templates/AA\ Testing/Cocoa-Python\ Document-based\ Application

Or, specifically:

./project-tool --help
Usage: project-tool.py [options]  

    Copies tree of templates or projects from  to .
    Before copying, it cleans up  by removing various bits of garbage.
    After copying, it transforms  by replacing strings with their Xcode
    template counterparts.

    The reverse flag can be used to reverse this process; turning an Xcode
    template into a working project.

Options:
  --version             show program's version number and exit
  -h, --help            show this help message and exit
  -v, --verbose         verbose
  -k, --kill-dest       erase  (no warning)
  -r, --reverse         reverse transformation (template -> editable project)
  -w, --working         try to make destination into a working project
  -n, --nib             rewrite NIB files to 10.5 text-only format
  -t TEMPLATEFILE, --template=TEMPLATEFILE
                        path to TemplateInfo.plist that should be used during
                        conversion

Nothing remotely Python specific about it. And, as some have noticed, the PyObjC Cocoa templates leverage the new Interface Builder file format (xib) such that all kinds of substitutions happen in the templated interfaces, too. As in: No more MyDocument ever again.

Wii / Mii Conclusion (and How to Make a Mii Editable)

Sunday, December 2nd, 2007
bbum's Mii

Just a bit ago, I complained about the fact that my Mii’s were no longer editable after Nintendo had fixed my Wii’s bad video problem.

Well, my Mii is now editable. But I still lost all associated game data.

First, how to make a Mii editable:

  • Go to the Mii Channel and transfer the desired Mii to a Wiimote.
  • Grab Mii Transfer and download the Mii file off of the Wiimote. I found that this worked best by turning of the Wii during the transfer.
  • Grab Mii Editor and use it to edit the Mii file. You can grab a portrait of your Mii, too. Mii Editor is an Adobe AIR app and, thus, you’ll see all kinds of fun security warnings and bootstrap installs off the web page.
  • Edit the Wii ID to match the last 4 octets of your Wii’s MAC ID. Or something. The documentation sucks on this. I just created a bogus Mii, slapped it on the WiiMote and used it as a template for the Wii ID for my Mii.
  • Use Mii Transfer to slap the edited Mii back onto your Wiimote.
  • Dive into the Mii Channel and transfer your Mii off the Wiimote. Since the Wii ID changed, it’ll show up as a new Mii. You’ll want to delete the old but that leads to seemingly unavoidable data loss.

Why?

Because each Mii has a Mii ID and a Wii ID embedded in it. The combination of the two create a globally unique identifier such that Mii’s can meandor about without risk of IDs colliding.

As Ryan pointed out on the original post, Wii’s with a different Wii ID than the system they are currently visiting cannot be edited and, as a result, cannot be the designated artisan in the Check Mii Out channel.

Back to the data loss: because visiting Mii’s can participate in games on your system, games must store the data keyed on both the Mii ID and the Wii ID.

As soon as you change the Wii ID, game data will no longer be associated with that Mii. Delete the original and the [some?] games will create a random Mii to own that players.

I opted to lose my game data. Clearly Check Mii Out is only but one game where editing your Mii will be requirement; where the Mii used must be “homed” on the Wii participating in the activity.

So, really, about all I saved was my Mii’s über-fantastic design. Which I changed in Mii Editor anyway.

If I correctly analyzed the situation, Nintendo screwed up by using the “meaningful primary key” pattern. The Mii’s unique identifier should be entirely isolated from any other meaningful information. The Wii ID should have remained in an isolated field.

Roger Being Roger

Sunday, December 2nd, 2007
Roger & Banana Tree

Roger decided to grab my boots and Christine’s gardening hat for a bit of backyard adventuring.

Here, he is hanging out in front of the banana tree.