Archive for the 'Software' Category

About a year ago, we picked up a 46″ Sony Bravia LCD TV (KDL46XBR2). Generally, a gorgeous monitor that has loads of inputs and, thus, has become the all-signal-switchbox for the various game consoles, media players, and computers that may be hooked up at any one time.

Great picture and generally easy to use. Amusing, too, that the manual came with a GPL license notice with a hyperlink to download source. Turns out that the UI is implemented via Linux (and, yes, Sony has a whole “source distribution center“).

However, it is not without its flaws and some of them are just so embarassingly stupid in terms of the concious Industrial Design choices made.

Click on through for the gory details.

Read the rest of this entry »

I use an AirPort Express to pipe any one of the 17,000 or so tracks from our master iTunes library into my work room / chillout space.

Works great, but getting to the UI just sucks. To select songs or play/pause, I have to wake up my MacBook Pro, unlock the screen, bring up screen sharing, and mess with iTunes. Tedious and annoying.

The moment I first touched an iPhone, I immediately thought “Damn! This would make a great remote for iTunes!”.

And it does!

You just need the right bit of software…

About 2 minutes after grabbing a demo copy of Remote Buddy, I purchased a license. It includes an AJAX based GUI that allows for easy control of iTunes. Way beyond simply play/next/pause/volume, it offers ratings, full access to the library, and — even — the ability to select which speakers to send the music too!

And that is barely scratching the surface. It can also control a slew of other functions on the computer and can even offers screen sharing functionality.

Read the rest of this entry »

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.

A few weeks ago, the SWT folks came out to Apple to learn a bit about Cocoa & Leopard.

Very early in the week, they discovered the BridgeSupport generated XML metadata that describes almost all Objective-C and C APIs on the system (and is included with user installations of Leopard).

Using that, they whipped up a tool that automatically generates a set of Java classes that mirror the Objective-C classes, with all the necessary glue bits underneath.

End result? SWT apps are now Cocoa apps. The goal is to host Eclipse on top of this version of SWT and they already have some success on that front.

Very cool.

All of this work has been pushed back into the SWT repository and they have now put out a call for help from the community.

In short, Yes. But not without some pain.

You can grab an example of the Python and Ruby bridges working together in a Cocoa application from either this downloadable zip or from this Subversion repository (in case something actually changes).

It works. Sort of. Ironically, this likely would have worked better under the pre-BridgeSupport versions of RubyCocoa and PyObjC.

Specifically, RubyCocoa and PyObjC both assume that nothing else might have loaded the dynamic libraries that are automatically generated by the gen_bridge_metadata script. So, either bridge will quite happily attempt to load /System/Library/Frameworks/Foundation.framework/Resources/BridgeSupport/Foundation.dylib and then barf mightily when the other bridge has already loaded the same dylib.

The example is rife with silliness related to catching the resulting exceptions and ignoring them. Worse, the fallout is such that from Foundation import * doesn’t actually cause the Objective-C classes to be defined within the importing module.

There is a back door — objc.lookUpClass() — but this is yet further evidence that, at this time, mixing these two languages in a single Cocoa application is not anything more than a silly hacque (as the SVN repository subdir indicates).

What does it do?

Not much, really.

• Start with RubyCocoa Application Template (because I can deal with brokeness in Python, I wanted to start with something working in Ruby)
• NSApp Delegate written in Obj-C
• Finish loading hooks used to bootstrap PyObjC/Python (with gross exception ignoring goofiness related to the dylib)
• Bind a table view to an array of dicts where each dict has the key “name” leading to a string value bound through array controller.
• Array controller bound through app delegate method.
• App delegate returns array of dictionaries by calling python based NSObject subclass.
• Python based NSObject subclass composes an array of dictionaries (all python) from a combinatio of Python strings and Ruby strings by calling an instance of a Ruby based subclass of NSObject.

Very little code. Lots of moving parts. Some gears grinding. Maybe even a gear tooth or four missing. Enjoy.

OK — I finally got around to actually following the instructions on this red sweater post. Ahh… much better.

Now MarsEdit actually shows me content pretty close to how it’ll look when published. This should greatly reduce the # of round trips when integrating pictures and text.

Got it mostly working in about 10 minutes. Still not quite full fidelity; flickr and google content doesn’t show up, but that is more of a feature than a bug.

Tedious, but worth it.

My first Nintendo Wii was a lemon; it suffered from the video corruption issues related to GPU overheating and/or failure. Nintendo was extremely efficient at addressing the problem, not only replacing my Wii but also migrating all data — downloaded virtual console games and Miis — to the new Wii.

Or so I thought.

It appears that the Miis were migrated and not restored to the new system. That is, the system believes that the Miis were copied from some other system (which, technically, they were).

Why is this a problem?

Because I cannot edit Miis that I created on the original system nor can I use my Miis for new features like the Check Mii Out channel.

At this point, it appears that my only recourse is to recreate my Miis. All of them. Including losing all saved data, scores, accomplishments, etc…

Sigh.

I have a technical support ticket open with Nintendo. Hopefully, since it was their screwup, they’ll have a fix. Though, honestly, I can’t imagine sending my Wii to Nintendo just to preserve my Pro Golf rating and my 1.45kg of brain.

If you have had your Wii serviced by Nintendo and said service involved replacing the Wii, you might want to see if your Miis are really your Miis, too!

A while ago, Flying Meat released Acorn, an image editor built with a focus upon simplicity.

I have never much been into image editing. I’m simply not smart enough to use PhotoShop and don’t have the interest to invest the time necessary to overcome my mental limitations in the face of that application.

The last real image editing I did invovled 2-bit black and white icon editing on NeXTSTEP.

I do, however, have a certain passion for whole image editing. That is, I like taking photos and I like tweaking ‘em a bit here and there to emphasize whatever it is that I want to capture.

So, with that said, I’m not even going to try to review Acorn beyond saying that it really is simple enough that a genre-incompetent user like me was able to launch the app and get done exactly what I wanted with very little spastic monkey style interaction with the user interface.

I.e. Acorn works. Acorn is simple. And Acorn did what I wanted with minimal fuss and, in this case, fluid integration with Aperture as its external editor.

GraphicConverter — an application that I purchased long ago, without regret — has been deleted. Whereas GraphicConverter is a more powerful application, the user experience pales in comparison to Acorn.

I would gladly pony up the $40 for a license to Acorn. But I didn’t have to.

As a way of saying thanks for my involvement in PyObjC over the years, the fine folks at Flying Meat sent me a complimentary license. Thank you. Seriously. Very much appreciated.

You see, Acorn has a plugin model and you can write plugins in either Objective-C or Python. Python modules are written via PyObjC. Brilliant. Elegant. Love it.

Is speed a problem? Not really. Most of the work in the plugins will be done by CoreImage filters or the like; Python is the configurating glue on top.

Very, very cool.

Objective Development relased Little Snitch 2.0 today.

Little Snitch is an outbound firewall, more or less. That is, it monitors all outbound connections and warns if an application makes any kind of connection for which there isn’t a rule permitting said connection.

The warning panel that comes up allows the user to allow or deny the conneciton and to do so one time only, until the app in question quits, or foreever. You can also specific that the app should only connect to a specific server and port, a specific server, a specific port (HTTP, for example), or any connection at all.

LS has an awesome rule editor built in and 2.0 adds a really neat traffic monitor.

All in all, it is a beautifully designed and highly functional piece of software.

I tend to run Little Snitch all the time. It can be a bit noisy when it is first set up, but that is quickly rectified as you refine your rule set.

Little Snitch has busted a handful of applications that “called home” or made connections to surprising places. (I busted an Apple application that was doing so — it was an accident and it was fixed before the software as ever released).

Ronald comitted the source for PyObjC 2.0 into the public repository.

It can be found at PyObjC 2.0 trunk (http://svn.red-bean.com/pyobjc/branches/pyobjc2).

The NEWS.txt file is extremely illuminating as there were tons and tons of changes and bug fixes in 2.0.

It cannot be emphasized enough; this is a huge release for PyObjC. As big as when PyObjC first gained subclassing (which wasn’t until about 7 years into its 14 year history). Go read the NEWS file; both major enties on PyObjC 2.0.

Note that libffi on Leopard is fully 64 bit and, thus, PyObjC should be mostly ready for 64 bit, though it was neither built for, nor tested with, 64 bit.