The Road to MacGDBp, Part I

Posted on June 2nd, 2008 at 4:33 pm, filed under Uncategorized. Tags: , , .

Inmy last pipeline update, I said that MacGDBp would be out by May. Unfortunately, I’ve run into two bugs that I’m not quite sure how to work around. One of them involves NSXMLDocument raising assert() messages for what appears to be valid XML. Weird, right? So instead, I’m going to write an article about MacGDBp in hopes of whetting your appetite for it until it’s done.

The idea for MacGDBp has been in my head for a long time. PHP debuggers are far superior to var_dump() and print_f() debugging statements. Unfortunately, only the Zend IDE was available — but it cost money and was ugly (i.e., not Mac-esque). Next came Eclipse with the web tool kit. I had a heck of a time getting the debugger to work and ultimately gave up. Additionally, it too was ugly. So I put up with my combination of BBEdit (and later TextMate) and var_dump()/print_f().

Fast forward a few years to the introduction of the Xdebug extension. This extension is absolutely fantastic, if only for the stack traces in errors and uncaught exceptions. But it also has a remote debugging function. For about a month, I used the packaged command-line demonstration tool and read XML to glean debugging information. Then at the end of July/beginning of August 2007, I made the decision to write a native Mac application for the Xdebug remote debugger.

Evolution of Design
It’s rare for me to design an application without first sketching out the interface on paper. But because this was such a straight forward project, I decided to wing it. The second commit in the git repository was “Laying out an unhooked basic interface for the system.” This was the first revision.

Yes, ugly. But it improved after some tinkering:

Then I realized that I was trying to re-invent something that had already been well-designed. So with the next iteration, I mocked up Xcode’s debugging window.

After designing a couple of toolbar icons, we get to the final design. This is how the application will look when launched and unconnected to Xdebug:

And there you have the final design. In the next couple of days I’ll talk about how I designed the icon in an effort to stall while I squash the last few bugs.

A Note about System Requirements
MacGDBp will require 10.5. And this is not because I don’t want 10.4 support, but MacGDBp relies on a bug that was fixed in 10.5. In Mac OS X, there is a class called NSTreeController that I use for the variable list. But under 10.4, parts of this class were not properly exposed and were very buggy. I found a work-around, but it relied on using private, undocumented API calls. In 10.5, Apple fixed the bug and exposed the necessary parts.


Blue Static - Blue Static Development » Blog Archive » The Road to MacGDBp, Part II said on June 5th, 2008 at 10:48 am :

[…] « The Road to MacGDBp, Part I […]

Maciej Łebkowski said on June 26th, 2008 at 8:42 am :

Is there any chance to get a Tiger-working-snapshot? This is a second (after fluidapp) must-have application for me that requires 10.5.
Thanks in advance

Robert said on June 26th, 2008 at 12:19 pm :

@Maciej: No, there is no chance. As I explained here and at the end of this blog post.

Leave a Reply