Interview with Tim Bumgarner - AStudio Engineer

I’m going to begin this edition of unScripted by extending our warmest thanks to Tim Bumgarner for taking the time out of his busy schedule to conduct this interview. I hope our readers here at MacScripter enjoy and learn from it and that they find atleast one of their questions answered here as well.

* MacScripter How long have you been with Apple Computer and have you always been in your present position? If not, what did you do before Apple?

Tim Bumgarner I started at Apple on April of 2000. Up until that time I had been with Symantec for nearly 10 years. Over those years I worked on several Macintosh projects such as Great Works, ACT! for Macintosh, Visual Page and Visual Cafe for Macintosh. Typically we would ship a Macintosh version, which sooner or later got canceled, then be moved to a Windows version or project. The last couple of years at Symantec were spent on Visual Cafe for Windows with no hope of ever doing any more Mac programming. I finally had had enough of Windows programming and thought, if I want to do Mac programming what better place than Apple? I had always wanted to work there but Symantec always took such good care of me, so I never bothered to apply (plus I hated to leave the great friends and teams there).

I had always been a fan of NextStep and when Rhapsody was being rolled out at Apple (and while I was still at Symantec) I was invited to attend a developer kitchen at Apple to learn more about it. I fell in love with Rhapsody (which of course became Cocoa) and Objective-C. Thus, when I started to look for a job at Apple (a couple of years later) I was looking for one where I could use both Cocoa and Objective-C as my development environment. Apple was looking for someone to do AppleScript Studio (which coincidentally was to be written in Objective-C and Cocoa using Project Builder and Interface Builder), a dream job for me if there ever was one. So I applied and they gave me the opportunity to work on this great project. I’ve been working on it ever since.

* MacScripter What exactly is your role at Apple?

Tim Bumgarner I’m the lead architect/engineer for AppleScript Studio. I get to work with very talented people, both on our AppleScript team and across the other groups to pull the various pieces together and make them all work to provide a real solution for our customers. It’s my responsibility to continually improve Studio in both quality and usability. This includes adding greater AppleScript coverage of Cocoa features, which is a pretty big chore. I’m always amazed at how comprehensive Cocoa is.

* MacScripter Are you a scripter yourself? If so, how long and what applications have you scripted regularly? Any favorites?

Tim Bumgarner I am now :wink: In my earlier days I did a little bit of scripting, but it mainly involved automating some Finder work. I played with it a bit over the years, but I never spent any really serious time with it. An ironic thing is that when I first started to work on the Visual Cafe team at Symantec, I had to work in the project window (which started life as the old Symantec C++ 8.0 environment which was very scriptable). Unfortunately it made the code very hard to maintain/understand so I ended up bypassing or removing most of that functionality for Visual Cafe. Now I spend all of my time making scriptable applications. Life has its interesting twists.

* MacScripter There are a significant group of developers from the Classic days who are big fans of Digital Technologies’ FaceSpan application development environment for AppleScript. It would be a shame for the Mac community to lose that brain power. Do you think FaceSpan will still have a role as AStudio matures?

Tim Bumgarner I can’t comment on this one, sorry.

* MacScripter Do you have any insight into the role of Scripting Additions under OS X? Will AppleScript Studio have any special relationship to them?

Tim Bumgarner We are trying to move away from Scripting Additions (traditional OSAXen) in favor of a new plug-in model. With the dynamic nature of Cocoa this makes it much more feasible. As far as AppleScript Studio’s involvement, that is yet to be determined, but I would hope to be able to create these plug-ins with Studio as well as with more traditional languages. We’ll have to see.

* MacScripter Is there any kind of push to give AStudio developers access to MORE of the system that Cocoa developers enjoy? (i.e. dock menus, preference panes, etc.) I know I’m very excited about the Drag-&-Drop classes and events introduced recently with 10.2.

Tim Bumgarner I’m always looking at ways to make more Cocoa features available in AppleScript Studio. Some are easier than others. Most of the things that you can do with Studio involve connecting scripts and handlers to objects in Interface Builder, so if a particular Cocoa feature isn’t accessible in Interface Builder then it takes a lot more work to make it available in Studio. Toolbars come to mind here. You can’t create toolbars in IB, so today you can’t create them in Studio applications.

It’s always an effort to prioritize the things that are most important and provide the most benefit to the majority of users. In AppleScript Studio 1.2 for instance, that meant adding real document support, drag and drop event handling and better data source support (sorting, appending), along with a few other features :wink:

* MacScripter Is there anything you might be able to tell us about more thorough, forthcoming AStudio documentation and how that might be coming along, either from Apple or third party publishers?

Tim Bumgarner In the short run, we’re about to release a significantly revised reference document for AppleScript Studio 1.2. It will be available at Apple’s developer website in both html and pdf formats. This version contains many more descriptions and examples, as well as links to related Cocoa documentation. In the long run, we’re planning on updated conceptual documentation that will include many recipes for common tasks. As far as third-party publishers, any efforts are a welcome addition. We’ve already seen some great articles by Bill Cheeseman in MacTech Magazine, and there have been a number of web articles too.

* MacScripter I’ve always been a bit curious about the origin of the AppleScript Studio name. This seems to have caused some confusion early on for scripters who were new to application development. Since AStudio isn’t actually it’s own environment, in the traditional sense, but more a statement of the fact that AS code will compile within the Project Builder development tools. Can you give us some kind of background on why the separate name approach to what seems to be more of a feature extension to the existing tools?

Tim Bumgarner That’s an interesting question. The main reason that Studio became a reality was that it could leverage Project Builder and Interface Builder (in conjunction with Coca) to provide a way to build native Mac OS X applications using AppleScript. Studio applications are, for all practical purposes, simply Cocoa applications. In a sense, it’s a technology more than a product, but from a marketing perspective it’s easier to have a name to wrap it all in. Which is where the “Studio” portion came in. A list of potential names was presented and “AppleScript Studio” looked like the best fit. The word “studio” often reminds one of using various pieces of equipment to produce a finished product. Of course it leaves us with an unfortunate acronym (which still seems to bring a lot of enjoyment to the lists ;-). I did mention Sal is our marketing guy, right?

* MacScripter The presence of Objective-C and Cocoa can be intimidating to even seasoned AppleScripters. Do you have any recommendations to Classic scripters which might help their transition to AStudio?

Tim Bumgarner Keeping in mind that AppleScript Studio is built on top of professional grade development tools, it is designed to be useful to a wide spectrum of people. On one end of the spectrum are AppleScript writers that want to be able to add a user interface to their work flow solutions, or they’ve always wanted to write a real application, but lacked the classic programming skills. You can design your interface in Interface Builder, connect a few scripts and handlers, write a little bit of script and presto, you have a real application to drive your scripts. On the other end of the spectrum are Cocoa developers that want to be able to take advantage of other scriptable applications, in which case, they can add Studio functionality to their applications by linking in a framework, adding a menu item (or button or any other type of UI element) that is connected to a handler in a script and use AppleScript to do the communications. A lot of the import and export features of applications could be done in this way. I myself have written a couple of applications internally that are about 75% AppleScript, 20% call method, and 5% straight Objective-C, which puts me somewhere in the middle of this spectrum in my usage.

Since we have this wide spectrum, the presence of Objective-C isn’t all that surprising. The “call method” command was added specifically to provide a way for developers to access Cocoa objects and classes that otherwise wouldn’t be available or were not yet available. A front door approach to a back door, if you will. It’s been nice having that there, as it provides a way for me to give support or to work around problems in shipping versions of Studio that I wouldn’t have been able to address otherwise. I’ve been putting up solutions like this in my iDisk and pointing people on the Studio lists to them to help them out. I’ve consolidated all of these pieces into an example project that shipped with Studio 1.1 called “Support”.

I have a goal that anytime that I have to resort to using a “call method” command or use a bit of Objective-C code to do something I can’t do directly in AppleScript, that I will provide a direct way in AppleScript to do the same thing as soon as I possibly can. For instance, all of the support items in the “Support” example are now obsolete in Jaguar (Studio 1.2) as they have AppleScript counterparts.

There will always be a need for “call method”, but my hope is to be able to provide a way for you to build fully featured applications directly in AppleScript without ever having to the use “call method” command.

* MacScripter There is already a small group of AStudio-specific developers putting out some great applications. Do you pay attention to the work being developed with AStudio? Do you have a favorite application which you think is a particularly good demonstration of the power of AppleScript Studio? Apple’s tutorial files don’t count. grin

Tim Bumgarner It’s exciting to the see the applications that people are putting together with Studio. I try to download as many of them as I can and to spend a few minutes playing with them.

I don’t currently have a favorite application, but that’s mainly because I have my head down coding most of the time. I’m a look and feel type of guy. To me, the way an application presents its user interface is almost as important as how well it does its task. So when I see that someone developed a Studio application and followed the Aqua guidelines, presented their application in a clean consistent manner, then I tend to like those the most. Of course, if they do something totally cool as well, thats even better!

* MacScripter What do you think of AppleScript’s perceived Second Class Citizenhip role in years past (Among some seasoned users of traditional albeit more complex languages like C++)? Do you believe, as we do, AppleScript gains a new level of respect as a programming language with the introduction of AppleScript Studio?

Tim Bumgarner I came to Apple just as AppleScript was on the rise, so I didn’t get to see first hand some of the lower points. It’s still a bit of a battle sometimes to get people to understand the power that you can provide to people when you make your application scriptable. They can then use your application in ways that you never dreamed of. The really cool thing is how much easier it is to add scriptability to a Cocoa application than it is to a Carbon application. There really isn’t a good excuse (not) to have at least some level of scripting in a Cocoa application.

* MacScripter How big is the Jaguar’s litter box?

Tim Bumgarner I can’t comment on this, sorry :wink:

* MacScripter Will Studio development become the only, full-featured AppleScript UI, or are there still plans to continue to develop UI options and features in Standard Additions such as display dialog and choose from list?

Tim Bumgarner AppleScript Studio will be the primary means of doing UI work with AppleScript, with plug-ins to System Events providing a secondary means. As mentioned before, we believe that Standard Additions will diminish over time in favor of the plug-in model.

* MacScripter And, of course, the obligatory juicy tidbits question: Any super secret AppleScript Studio morsels you (or your management) are willing to let MacScripter in on? Can’t hurt to try, huh?

Tim Bumgarner No, and no :wink: