ATPM had the pleasure of interviewing Frank Vercruesse, author of ASM (Application Switcher Menu), last month. ASM is an extension to Mac OS X that provides OS X with the equivalent of a superior version of OS 9’s application menu. In addition to the customizable menu, ASM lets the user modify some of OS X’s application switching and window layering behavior, and it includes other enhancements to improve the transition to and enjoyment of OS X.

• • •

Tell us a bit about yourself. Where do you live and what do you do for a living? How did you get started programming, especially for Mac OS X, and what setup do you use when you develop projects like ASM?

My name is Frank Vercruesse. I am a 23-year-old student of computer science at the University of Leipzig, one of the bigger cities in Germany. And that’s where I live too.

I started programming more than ten years ago. At that time we had no computer at home. However, there was a study group for computer enthusiasts in the neighborhood. Most of the time we played only games, but I also wrote my first, simple programs there. In 1991 my father finally bought a computer. It was a Mac LC, which still runs fine by the way, and I played around a lot with HyperCard and explored almost every corner of the system using ResEdit. Later I learned C and some other programming languages.

As the long awaited public beta of Mac OS X came out last year, I was very excited about it. After a few weeks of tweaking, I was familiar with the new OS and its development tools. It took another while until I could write my first Cocoa program, because I had to learn Objective-C first in order to use the frameworks. For the development of ASM and my other projects I mainly use Project Builder and Interface Builder. My current machine is an indigo iMac (400 MHz G3, 384 MB RAM).

What gave you the inspiration for ASM? What do you think makes ASM special?

First of all I’m a big advocate of Mac OS X. As a developer I especially appreciate the Unix underpinnings that make the new system very stable and reliable. Anyway, I’m not so happy with some aspects of the new user interface. As a long time user of the classic Mac OS I’m used to clicking in the top right corner of the screen in order to switch between running applications. Of course, there is the Dock that more or less fulfills this purpose now, but old habits die hard. So I began to think about the reincarnation of the sorely missed menu and this has led to the development of ASM.

I don’t know if there is anything special about ASM. It’s my first program ever that I’ve released to the public and I’m happy that it became so popular.

What was the most challenging part in creating ASM? How did Apple’s lack of public documentation for the new system menus in 10.1 affect your project? What are—in general—the easiest and hardest parts in developing for Mac OS X?

In my opinion Mac OS X is a real relief from the developer’s point of view. Thanks to the memory protection it’s much harder to crash the whole system compared with the classic Mac OS. So if your application crashes permanently—a likely situation during the development process—you don’t have to reboot the machine every time. Furthermore, since Mac OS X is a true Unix system, porting code from other operating systems is now easier in most cases.

The tricky part—I can only speak for myself—is the lack of (public) APIs (Application Programmer Interfaces) for system wide customization of the user interface. There was a standard way for developers to do such things with the classic Mac OS. You were able to manipulate almost everything of the system with the help of a system extension. You know, this led to incompatibilities between certain extensions and it’s probably not a good idea to simply re-implement it for Mac OS X. However, Apple should really consider giving us developers the chance to modify some aspects of the system, especially the user interface.

As you already mentioned Apple doesn’t provide any documentation for building system menus. It’s a private framework that they obviously want to reserve for their own use—at least for the moment. Therefore the most challenging part in rewriting ASM as a menu extra (the actual term for system menu) was to find out how such a beast works. This was a tedious process that required some intuition. Though I’m now able to make my own menu extras, it’s actually a bad practice to rely on private APIs, since they are subject to change. In the worst case I’ll have to rewrite ASM again when the next update for Mac OS X comes out. But what were the alternatives? A less functional or no ASM at all!

You have been developing for OS X since the public beta. How has Apple’s developer support and documentation changed since then? Do you feel Apple sufficiently supports developers like you? What could they do better in your opinion?

Well, there is always something that can be improved, but I think in general the quality of their developer support is good. Apple gives away their developer tools and the documentation is also available on their servers free of charge. Maybe a matter of course but none the less a clinking good thing, especially for students like me whose finances are mostly tight.

Something I’d consider problematic is the still incomplete documentation, particularly for the Cocoa frameworks. Sooner or later you are confronted with the infamous “description forthcoming” statement. Though the situation has improved since the public beta, it could be better. Fortunately, there are some other sources on the Web and a few mailing lists that help to overcome these difficulties. Anyway, I’m probably not the one who should blame others for lack of documentation, but rather set my own house in order…

Some other improvements that I’d really appreciate: Apple should make the whole bug database accessible to all developers. A more comfortable search function for the mailing list archive would also be nice.

All in all my personal experiences with Apple’s developer support are positive so far. For example, I’ve posted a description of a bug that I found in Mac OS X to one of their developer mailing lists. A few hours later I got an e-mail from an Apple employee who confirmed the problem and provided a workaround.

What do you feel Apple needs to improve most in OS X, from a user’s point of view?

The Finder.

Tell us a bit more about the development process. What are the main phases, and how much time do you spend on each?

There are several approaches to software development, but my knowledge of the various theories is very limited. Unfortunately, I’ve never paid much attention to this topic in the past. So it’s actually a quite chaotic procedure instead of a well-ordered development process.

Sometimes I make a quick sketch in order to visualize the basic structure of the program, but I start coding without any noteworthy preparations usually. All I have is a more or less vague imagination of the program’s design in my mind’s eye. That is, I subdivide the whole program into smaller components. Each of these parts is implemented independently as far as possible. At the beginning there is only a simple code skeleton that actually does nothing. Then I add and refine features step by step, so the program becomes more complex a bit at a time. Sooner or later—when the basic features are working—I put the individual components together. The user interface evolves at the same time.

It’s hard to tell how long each “phase” takes. I have to spend a lot of time reading the documentation in between, since I’m still in the process of learning Cocoa. Mostly, there are different ways to achieve one’s goal and it’s not always obvious for beginners what the optimal solution is. Testing can be also very time consuming. Occasionally, you spend countless nights to find just one nasty bug.

Where will you focus in the future? Are we going to see a lot more development for ASM, or are you working on a new project?

The project that I’m currently working on is similar to ASM. It’s also a menu utility, but has a more general approach. You will be able to build your own, individual system menus with a few clicks. ASM will live on in the form of a plug-in for the new project. I hope to release a first version of the program in January. The basic features already work, but it is not yet very polished.

Thank you very much for your time. Good luck with your future projects!

Thank you.

Copyright © 2002 Daniel Chvatik, dchvatik@atpm.com.