GTD Exchange

Tuesday, February 12th, 2008

A Discussion of Hanselminutes Show #99

In this life, I’m in a peculiar position. During the day I’m a C# / .NET desktop application developer. However for the past several years my evenings have been spent exploring Cocoa and Mac OS X application development. I’m not sure if any of my readership (hi mom) subscribe to Hanselminutes, but the most recent episode, “What’s it like for Mac Developers - Interview with Steven Frank of Panic,” peers into the world of a mac developer from a .NET perspective.

Since I’m in the aforementioned position, I’ve decided to take this opportunity to expand on some of the items in the episode. Some were covered well, and some were glossed over. I’ve tried to garnish the most relevant points of conversation. Consider this post the parsley on Scott and Steven’s well-prepared entree.

Kernel Panics
The OS X kernel panic screen that Steve talks about is shown below:

NOTE: As an aside, the kernel panic screens can be customized, but there’s no way I’m going to vouch for the safety of this technique. Proceed at your own risk.

Applications and Packages
The “Show Package Contents” menu, accessible via ctrl+clicking an application in the Finder:

After clicking the “Show Package Contents” menu item, the finder will reveal the hidden folder structure inside the application. An application (a file with a .app extension) is a type of package in OS X. The Finder treats packages differently than other folders. There are several types of packages, and you can read about them and how the Finder handles them here.

Fat Binaries
The topic of fat binaries, or in Apple’s terms Universal binaries was discussed particularly well. As Steven explained, fat binaries are executables that have been compiled for separate architectures (i386, PowerPC, IA-64) and “glued” together. It’s a single file that contains binaries for multiple architectures, and was one of the techniques Apple employed to make the PowerPC-Intel switch easier for users. I’m not going to describe much here except for a little info on how to poke fat binaries.

file is a command line program to display information about a file. Below is sample file output for a text file:

rhmacbook:~ $ file hello.txt
hello.txt: ASCII text

Here’s the file command run on ls, the command to list the contents of a directory:

rhmacbook:~ $ file /bin/ls
/bin/ls: Mach-O universal binary with 2 architectures
/bin/ls (for architecture i386): Mach-O executable i386
/bin/ls (for architecture ppc7400): Mach-O executable ppc

The output states that the ls command is a Mach-O universal binary including binaries for both the i386 and the ppc7400 architectures. file is a great command in general, and can be used to make a great first guess at a specific file’s purpose.

file provides some rudimentary information about a fat binary, but the lipo command holds the real functionality when dealing with fat binaries. In addition to providing additional information about fat binaries, lipo can also remove, add, and modify the architectures present. As a lazy blog author and technology pundit, I’ll leave the full functionality as an exercise for the reader (hint: read the man page for lipo). However, to give you just a taste I’ll run lipo -detailed_info on ls:

rhmacbook:~ $ lipo -detailed_info /bin/ls
Fat header in: /bin/ls
fat_magic 0xcafebabe
nfat_arch 2
architecture i386
cputype CPU_TYPE_I386
cpusubtype CPU_SUBTYPE_I386_ALL
offset 4096
size 36464
align 2^12 (4096)
architecture ppc7400
cputype CPU_TYPE_POWERPC
cpusubtype CPU_SUBTYPE_POWERPC_7400
offset 40960
size 32736
align 2^12 (4096)

I’m not even going to pretend to know what some of this information is, but it appears to provide more detailed_info (snicker) about the various structures of the binaries included in the file. One thing I’d like to note is the magic number for a fat binary is 0xcafebabe. The only, very geeky, reason this is of interest is that the Java .class shares 0xcafebabe as a magic number. I brought this up in #macdev on freenode and was quickly informed that “fat binaries used that magic number long before Java was around.” And that, my friends, is our neat historical tidbit of the day.

Interfaces (like IPerson) in Cocoa
The discussion on interfaces was on area that needed a little more roughing out. Steven was a little vague about whether interface-like functionality could be achieved in Objective-C. Interfaces are implemented in Objective-C via formal protocols. There only caveat here is that a class can implement a formal protocol without actually declaring that it does. That’s a little weird, I know, but just roll with it.

Frameworks
Frameworks are the library objects in Cocoa, similar to assemblies in .NET. As Steven mentioned in the podcast, Objective-C is just an object-oriented superset of C, so Objective-C uses C-like libraries at it’s core. While .NET uses embedded metadata to provide information about the assembly contents, Objective-C still requires .h header files to describe library contents.

Frameworks provide a tidy way of bundling both the header files and libraries together in one logical package. The Objective-C compiler (gcc) can then use these frameworks as arguments to the linker flag. With XCode a lot of this is handled automatically. However, a developer may choose to compile from the command line. Frameworks ease the pain of traditional C builds, since referencing a framework will provide both the header files and library files, as opposed to listing include and linker directories as arguments to the compiler.

Frameworks also provide some additional support infrastructure for versioning and non-code resources. A little more information can be found at Wikipedia.

Building UIs with Interface Builder
Apple’s tool for creating user interfaces in OS X is Interface Builder. Interface Builder is very similar to the designer in Visual Studio in terms of function. However, the structure of the data generated by the two tools are very different. The Visual Studio designer generates code, and as of VS2005 in the C# world GUIs are described by a designer partial class file. The layout and structure of the GUI is described in code in this file. So, the designer uses code-generation for UI development.

While Interface Builder is another drag-and-drop WYSIWYG editor, the GUI objects are actually saved as binary data (sometimes called freeze drying) to a .nib (NeXT Interface Builder) file. Object interconnections are also stored in this file. At run-time the objects are simply unpacked from the file and attached to the binary.

The Importance of Model-View-Controller in Cocoa Development
Cocoa development adheres strongly to the Model-View-Controller design pattern. Almost all cocoa frameworks provided by Apple fall into this grouping. From the views in Interface Builder to the models generated by Core Data, MVC can be seen throughout the Cocoa architecture.

Bindings
I mentioned MVC in the previous paragraph to introduce the bindings technology that was introduced in OS X 10.3. Bindings are very similar to data binding in .NET (for example, binding a DataGridControl to a DataSource). Binding technology allows developers to link data model objects directly to view objects, in an MVC sense. Thus, bindings allow the developer to skip writing some controller-layer logic entirely.

For example, say I have a GUI that has a series of text boxes used for personal information data entry. The information entered might be something like first name, last name, address, age, favorite child’s name, etc. Let’s also, for the sake of continuity, say I have a person class that has strings that represent all this information. With the proper bindings orchestration I would be able to “bind” (now it gets clearer) the text boxes to the fields of the person class without writing any “glue code” (aka controller code). This would free me from having to catch events on those text boxes and synchronize the person object with the information the user entered.

Saturday, January 26th, 2008

Changing a Window’s Color

In my last post, I was about 90% successful with creating a custom-colored window that behaved the way I wanted. Allow me to define the way I wanted:

• The window takes on the desired color (obviously)
• There is no visible separation between the title bar and the rest of the window
• The window is only draggable via the title bar

I know bullets two and three seem to conflict as far as good UI design is concerned, but I’ve seen this behavior in a lot of apps out there. I like this behavior because it seems to be the most used.

As I mentioned in the previous post, it was really easy to get about 90% of the way there. After researching the problem, it was just as easy to make it to 100%.

This guide is targeted at Xcode 3, since that’s what I’m using. The only difference will be where to adjust the settings in Interface Builder, which is trivial. First, create an object that has access to your window. In this example I’ve created the time-tested AppController object in Xcode (a plain Cocoa class). Add an outlet (I did this in code) to the NSWindow:

After creating the new class in Xcode, open MainMenu.nib to start Interface Builder.

NOTE: This section will actually be different for Interface Builder 2 and 3. Once again, I’m going to explain using Interface Builder 3, but if you know how to create a custom object in Interface Builder 2 the process isn’t that different.

Drag an NSObject from the palette into the MainMenu.nib window (the one with File’s Owner and Window object). Set the subclass to AppController (or whatever you named the class we created in the previous step). Next, CTRL-drag a connection from the instantiated AppController to the Window object and connect it to the outlet you’ve created in the code (_window in my case).

Now for the last step in IB. Select the Window object and bring up the inspector palette (Cmd-i, or press the blue i button). In the Attributes tab of the inspector, check the box labelled Textured:

That’s all you’ll need to do in Interface Builder, close it down.

Now for the final step. In the AppController.m file, add a little code to the -(void)awakeFromNib method to configure the window:

And that’s it. You can place use whichever color you like. In my case, I used red. Here’s what our window looks like:

Not really much to write home about, but this is the appearance I was hoping for. Also, if you attempt to click and drag the window around anywhere other than the title bar, it won’t budge. This is what the aptly-named setMovableByWindowBackground:false call does.

This is such a simple process, you may be tempted to make all your windows stylized (which I highly recommend against). I think the stylized theme really needs to match your application. I’m not even sure if I’m going to stick with it in SpriteEdit, I was just curious if I could do it.

Download sample code.

Technorati Tags: Cocoa

Tuesday, March 20th, 2007

Configuring a Development Environment - ACM Presentation

Slides (PDF)

Links:

Wikipedia C# Page
Wikipedia Java Page
Cygwin
GLUT for Windows
Simple GLUT Examples
Visual Studio Express Editions
Apple Developer Connection

Wednesday, January 17th, 2007

GTD with Remember the Milk (Software)

A friend of mine sent me an article about integrating a GTD system with a task tracker called Remember the Milk (its free). The article discusses how to integrate GTD ideas, including context tagging, and marking items as next actions. A good starting point if you’re in the market for GTD software and a way to integrate your system.

Read the article.

Tuesday, January 16th, 2007

Stop Carrying that Anchor

As I was leaving work today, a significant thing happened to me: I removed the shoulder straps from my laptop bags. Well, maybe not a big deal to you, but it was for me. Why? Because I’d been keeping the straps on the bags “just in case” I ever needed to carry them around on my shoulder. Consequently, I drug the straps through mud, caught them on door handles, and had them slide off my shoulder. I would perform voodoo black magic every time I carried the bags: wrapping them around my hand, tucking them in the bag, anything to keep them from dragging on the ground.

So today, as I was looking at the bags I finally decided it wasn’t worth it to keep the straps attached and simply removed them. For whatever reason, I felt some relief. It made no sense at all, but it was like my shoulders said, “thank God, he finally got it.”

What about you? Are you carrying around any laptop bag straps you can get rid of? Think about it. Your body, and your mind will thank you. Next up, convincing myself I don’t need to carry around two laptops (I sure love my Mac).

Saturday, January 13th, 2007

Is Efficiency Overrated?

I’ve been trying to find someone to do a site design for GTD Exchange. Since I suck at design, I contacted an artist friend of mine to see if he could help or possibly provide another resource. During the conversation, he asked of the sites purpose, and I explained what GTD Exchange was all about. When GTD was mentioned, his response was, “GTD? Getting Things Done? I hate GTD. Efficiency is overrated.”

I was a little taken aback by this statement. On the one hand, I understand. At least in a work environment, if you’re efficient and do well, you’ll typically be tasked with a higher workload. Depending on your situation, this may or may not be desirable. You may appreciate the added responsibility, or you may detest it. But work isn’t the only environ that we have tasks to accomplish.

In our daily lives, we all have things to “get done.” Take the animals to the vet, the kids to soccer practice, pick up groceries, or clean the house. This won’t ever change. GTD isn’t a system, its an idea you apply to daily life. Everyone has different needs and tasks, and we all must approach them differently. GTD is about creating a system that’s right for you.

Lastly, as the insightful Merlin Mann points out, GTD is for those of us that are naturally disorganized. If we didn’t have a system, we’d get nothing accomplished. We adopt GTD because we can’t maintain our lifestyle in the current state.

So, if you wonder what GTD is about, its about creating a system that works for you. We’ll always have things we need to accomplish, and the more intelligently we organize and attack those items, the more effectively we’ll be able to use our time. And that’s always a plus.

Thursday, January 4th, 2007

Using Wordpress for Collaborative GTD

Do you work in a collaborative environment? Would you like an easy way to implement GTD for all members of your team? Why not use Wordpress to help out? Create a category for each project, and create posts to represent tasks within each project category. You could even create a completed category for each project to move tasks to upon completion. You could even use this in a non-collaborative environment to easily bring your GTD system on the internet. With a program like Ecto you can remove login headache and cache all tasks on your local machine. While it may seem like the poor-person’s task tracker, its also a viable medium for a GTD implementation.

Thursday, January 4th, 2007

Using the Nintendo Wii for Notification

One thing I’ve notice about the Wii is how easily I recognize a new message is waiting. Whenever a new message arrives, the little blue bezel around the disc slot pulsates with blue light. It draws attention without being overbearing. You can reach any Wii by emailing wInsertConsoleNumber@wii.com.

If you don’t check your email at night, but want to be notified of important events, have the event forwarded to your Wii via a script. That way, you don’t have to waste time continually checking on that specific event, and the Wii will gently notify you of high-priorty changes in the outside world.