Living Code

I recently tried out the beta of Macromedia Flex Builder 2, and was quite impressed. I normally avoid Flash on principle, but it has some pretty powerful tools built in. It feels more limited than Apple’s Interface Builder, but it has one feature that I’ve been dying to see in IB: You can flip between visual drag-and-drop widget mode, and editing the layout as XML. Interface Builder so needs this ability. It would help for folks writing about developing for OS X (sometimes 100 words is better than half a dozen pictures, and trying to show CTRL-dragging in a still picture is an exercise in futility), and it would help when you come to a new project (or one you haven’t worked on in awhile) and want to get a feel for what methods and event handlers are hooked in to various widgets. Heck, it would help with automated tools, with testing, with grep. Just do it, Apple, or hire me to do it.

The other part that was interesting for me was that Flex Builder runs inside of Eclipse. It’s been a long time since I’ve tried Eclipse and I was pleasantly suprised. It was fairly snappy, not too confusing to find my way around in, and looked better than I remembered. Of course, I was running it on a dual 3GHz Windows box, so I might be disappointed once more if I ran it on my Powerbook, but my brief encounter with it didn’t suck, which was a big improvement.

Of course, neither of these developments are going to lure me away from Python and Vim any time soon.

In my last post I promised a Hello World program for PyObjC + Renaissance. If you haven’t got those installed, or aren’t sure, please check out the prerequisites.

We’ll be creating four files, each of which will be a template for upcoming examples. The menus will be defined in MainMenu.gsmarkup, the application window will be in MainWindow.gsmarkup, the application code will be in hello.py, and the py2app build script will be in setup.py. There is no reason that the menus and window have to be separated this way, but it will serve as an example for later, more complex applications, when you’ll want to load in code from multiple files.

MainMenu.gsmarkup

<?xml version="1.0"?>

<!DOCTYPE gsmarkup>

<gsmarkup>

    <objects>

        <menu type="main">

            <menu title="Hello World" type="apple">

                <menuItem title="About Hello World"

                action="orderFrontStandardAboutPanel:"/>

                <menuSeparator/>

                <menu title="Services" type="services"/>

                <menuSeparator/>

                <menuItem title="Hide Hello World" action="hide:" key="h"/>

                <menuItem title="Hide Others" action="hideOtherApplications:"/>

                <menuItem title="Show All" action="unhideAllApplications:"/>

                <menuSeparator/>

                <menuItem title="Quit Hello World" action="terminate:" key="q"/>

            </menu>

            <menu title="Edit">

                <menuItem title="Cut" action="cut:" key="x"/>

                <menuItem title="Copy" action="copy:" key="c"/>

                <menuItem title="Paste" action="paste:" key="v"/>

                <menuItem title="Delete" action="delete:"/>

                <menuItem title="Select All" action="selectAll:" key="a"/>

            </menu>

            <menu title="Window" type="windows">

                <menuItem title="Minimize Window" action="performMiniatureize:"

                key="m"/>

                <menuSeparator/>

                <menuItem title="Bring All to Front" action="arrangeInFront:"/>

            </menu>

        </menu>

    </objects>

</gsmarkup>

MainWindow.gsmarkup

<?xml version="1.0"?>

<!DOCTYPE gsmarkup>

<gsmarkup>

    <objects>

        <window title="Hello World" closable="NO" >

            <vbox>

                <label>Hello World!</label>

                <button title="Click this button to quit" action="terminate:"/>

            </vbox>

        </window>

    </objects>

</gsmarkup>

hello.py

from Foundation import *

from AppKit import *

from Renaissance import *

class MyApplicationDelegate(NSObject):

    def cut_(self, sender):

        pass

    def applicationDidFinishLaunching_(self, notification):

        NSBundle.loadGSMarkupNamed_owner_('MainWindow', self)

def main():

    app = NSApplication.sharedApplication()

    delegate = MyApplicationDelegate.alloc().init()

    app.setDelegate_(delegate)

    NSBundle.loadGSMarkupNamed_owner_('MainMenu', delegate)

    NSApp().run()

if __name__ == '__main__': main()

setup.py

'''

Minimal setup.py example, run with:

% python setup.py py2app

'''

from distutils.core import setup

import py2app

setup(

    data_files = ['MainMenu.gsmarkup', 'MainWindow.gsmarkup'],

    app = ['hello.py'],

)

Commentary

OK, so 80 lines of code may seem excessive for a Hello World program. We could certainly do it in less, perhaps 20 total lines of Python and Renaissance. But what we have here is a complete working Cocoa application which behaves properly to standard keyboard shortcuts, supports services, etc. And that’s not bad for 80 lines of code.

I’ve been working with PyGame a lot and it’s been hard slogging. PyGame is great for moving images around quickly, but I’m more interested in vector drawing, native UI widgets, and higher-level events than I can get from PyGame.

So lately I’ve been turning my attention more and more toward PyObjC. I’m writing games for my kids, who are playing them on OS X, and I’m much less willing to make sacrifices to get cross-platform behaviour. And when I only have a few hours a week to write code, I need to focus on high productivity tools. So I’m writing Cocoa code, using Python, and it’s great. Bob Ippolito, Bill Bumgarner, Ronald Oussoren, Jack Jansen and the rest of the MacPython developers have produced an amazingly great tool. on top of Apple/Next’s highly evolved Cocoa framework. The mapping is so good that standard Cocoa references work for me to bootstrap my way up the Cocoa learning curve, my favorite reference being AppKiDo, which gives a series of views on every class (being able to separate instance methods of a class from all the intance methods it inherits, for example). Great stuff.

My only problem with Cocoa development (besides all the things I still have to learn about it, I’m not yet a proficient Cocoa developer) is the reliance on Interface Builder and NIB files. I think Interface Builder is one of the best visual layout tools I’ve used, and it’s great as far as it goes, but the problem is that you pretty much have to use it. I’ve tried to create applications which built their own interfaces from code, but I was unable to get the menus working because the Cocoa framework expects you to load the menus from a NIB at startup. I’m sure it can be done, but I couldn’t figure out how, even with the help of the MacPython mailing list and wiki.

And NIB files, which is how Interface Builder stores the interface, are a problem for me too, because they are serialized objects, not descriptions, so they are binary goop which is inaccessible except to Interface Builder. I can’t grep them or do a global search-and-replace if I change a method name. It’s hard enough for me to find the right places in IB to hook into my application, but finding all the places later which I need to change when my code changes rapidly becomes nightmarish.

And all this leads to examples like Build a text editor in 15 minutes or An example using NSDocument which consist of a few lines of code (the power of Cocoa) accompanied by tons of screenshots of Interface Builder and paragraphs of instructions for wiring up your application. Even worse, as the second example demonstrates, since the author no longer hosts that article and Google doesn’t cache the images, the screenshots no longer exist.

One more gripe. Because IB stores serialized objects, it doesn’t pick up changes to your code for those object unless you specifically force it to. So what I want in a UI tool:

• Declarative
• Simple and powerful
• Able to replace NIB files and Interface Builder
• Text-based, not binary
• Agile for rapid development, adapts to rapidly changing code
• Able to specify simple apps completely, in code, without resorting to pictures or talking the user through mouse gestures

And the best part is that I think I’ve found it. More in my next post.