Archive for the 'Developing on Mac OS X' Category

A little bit on project management

Tuesday, November 6th, 2007

I just wanted to talk a bit about how I use to manage the projects I’m working on. I (ab)use Midnight Inbox for my project management. It may not be created for this task, but I’ve never really understood the whole GTD idea; maybe I should read the book, but I’m probably too busy for that 😉

Anyway, Inbox provides a REALLY great way to me to sort my stuff. I probably only use a small fraction of the app but for what I need it’s unbelievable reliable to me.

As you can see on the screenshots there’re several categories on the left like Collect, Process, Organize, etc. From all these I only use the organize category.

Inbox Categories

For each of my Projects I created a Item there and whenever I think of a new feature for some project I just add it there. When I finish a feature on the list i just check it and it’s grayed out but still there.

I started to put all the complete features into another item, named after each version that I published:

Inbox Screenshot

That’s really helpful when writing the change-list for sparkle and having such a bad memory like I do. 😉

I’m not sure if other people use the same sort of tool to manage their projects and I’m sure there’re tools that have more and better features, but I’m only working on my projects during the weekend so there can be quite a long break between the implementation of two features or even during one feature and Inbox was the simplest way that I found to help me keeping track of the work.

As of 10.5 there’s also a nice todo list in which is really helpful, but I tried it and didn’t like it as much as Inbox for my project management. I only use for my daily todo-lists now 🙂

Compiling Automator actions in Leopard for Tiger

Wednesday, October 31st, 2007

Some of you may have read that part of Automator Programming Guide that reads:

An action compiled in Mac OS X v10.5 will not work in v10.4 due to binary incompatibility.

That is completely inaccurate. If you compile using the 10.4 SDK it will work in 10.4 without any problem (as long as you don’t use any new feature).As I couldn’t find much information about that (yet) I thought it would be useful to share my testing results with you.

NSFont fontNamed:@”Arial”

Wednesday, October 24th, 2007

Using fonts in a drawing method should be a pretty common thing. I use that in CuteClips for rendering the text of each clip. However, one should not believe that [NSFont fontNamed:(NSString*)aFontName] is sort of appropriate for using it there. This method is hell slow. If you’re going to draw some NSString instances with special attributes, you should really use caches for the font. The speedup is quite reasonable.

NSAttributedStrings and autorelease

Sunday, August 12th, 2007

First of all, greetings from C4[1]… it’s really nice here, and I absolutely enjoy the show.

I have been trying to track down a bug in CuteClips3 these days. It was a very strange bug and it only happend with faulty RTF data on clipboard. But that alone wasn’t the reason for the crash. The crash was one of those nice memory bugs that occur when an object is released and then accessed…sometimes it works, sometime it doesn’t, most time it crashes, but you just can’t really debug it.

So finally i found out what went wrong with all this:

	[[[NSAttributedString alloc] autorelease] initWithRTF:[self data] documentAttributes:nil];

So I was autoreleasing this new object, but then it was initialized with faulty data. Trying to initialize attributed strings with faulty data is returning nil, so this is not a big deal. The problem is, that the initialize method will also release the attributed string while it was already marked autorelease. So the autorelease pool will also try to release it.

So the correct order would be like this:

	[[[NSAttributedString alloc] initWithRTF:[self data] documentAttributes:nil] autorelease];

That fixed the bug for me 😀

So now I’ll just continue to enjoy the rest of C4, although it’s almost over now.


Deployment and Logging, a different approach

Saturday, June 16th, 2007

One of the main debugging techniques in Mac OS X is logging using NSLog. It’s quite simple and easy to log some useful information with it, but it’s even more simple to print a real huge amount of data to the console that is not really interesting and helpful.
When it comes to deploying some application it’s not really a good idea to keep all those NSLogs inside the code. A simple

	#ifndef debugging NSLog(...)

really helps a lot there. If you add the “debugging” to the compiler option: “Preprocessor Macros” in your debug build options, this should remove all the NSLogs from your code when you deploy. Not much new stuff so far, I think 😉

But what if you want to keep the logging ability inside your application? What if you want the user to be easily able to enable logging in his built without sending him a new version? When I first thought about this question I instantly thought about the plugin enable/disable feature of Finder: if you open the info panel on an app (cmd-i) you’ll see a plugins section there.
So I created a plugin that, when enabled, will activate logging in my app again. And while it is disabled, there wouldn’t be any logging at all. The plugin is very simple, it only contains one class and upon initialization it will set a boolean to true.

This boolean will be read by a function called BSLog(). The function is implemented like this:

	BOOL bs_enableLogging;
	void BSLog(NSString *format, ...)
		va_list ap;
		if (bs_enableLogging) 
			// if logging is enabled, pass the args to NSLogv

You can see it’s really simple, it only passes the arguments to the function NSLogv if bs_enableLogging is set. Of course you can enable and disable this bool everywhere in your app if you want, even if it doesn’t make much sense.
After creating the plugin, it also has to be installed in the application. The default place should be “ Disabled/”. Unfortunately there’s no such folder in the info panel for the “copy files”-build phase. There is however a destination called “Wrapper”, that’s the “” folder, so you’ll have to write the path like: “Contents/PlugIns Disabled”.
In the application code you have to load the plugin of course. Using the BSPluginLoader bundle, this is just one line of code.

This should be all I think. If you want to use logging during development, but still want to use the plugin, you should set the following Preprocessor Macro in your debug build setting:”BSLog(ARGS…)=NSLog(ARGS)”. This will ensure that NSLog is used instead of BSLog and the plugin is ignored.

I think tomorrow I’ll upload the archive to CodeBeach, but first I’ll upload something different, so stay tuned 😉


floats in AppKit

Thursday, May 17th, 2007

Recently I wanted to automatically center a NSView inside a window. But the buttons inside this view were displayed pretty strange:

You can see, the buttons and the textfield are drawn blurred and the buttons have a stripe on both sides of their label.

It took me quite some hours to figure out what was going wrong, but then I found the bug: floats with a fraction portion.
AppKit uses floats all over the place, but it seems those floats have to be truncated in order to draw the view properly. After using truncf(aFloat) everything was displayed as one could expect it:

I attached a sample project to this post, so you can have a look yourself.

sample project

HexEdit for Intel macs

Wednesday, March 14th, 2007

So when it comes to using a Hex editor, my favorite choice has always been HexEdit. It’s fast, works great, but has some flaws here and there. But anyway, I love this editor by heart. Now on my MacBook Pro I wanted to use a universal binary of that app. Thanks to the fine guys at kaintek there’s an already precompiled version of HexEdit for intel macs.

If you guys read this: could you please release the source-code, or fix the bug with the color scheme, it’s not saved, when it changes. But anyway thanks for the build!


Creating Xcode Templates

Tuesday, March 13th, 2007

Creating templates for Xcode projects is not an everyday duty of developers. It’s quite tricky but can be really powerful. It is even possible to customize nib files!

I wanted to create a template for a BSInspectors plugin these days. My intention was to have most of the tedious work done by Xcode when the project is created, so that the developer can focus on writing the code for the plugin.

The first step before the template is created, is to create a sample project. The BSInspector plugin project has two targets, the inspector and the debug object. Both targets have one class each by default. They have a plist with all the settings and the targets build options are also set. That’s nothing special yet.

However, my idea of this plugin was, that the classes for each target are created automatically based on the project name. Creating a project named “Window” should result in a class called WindowInspector and a class called WindowDebugObject. The .m and .h files should be named accordingly of course.

To allow for such fancy stuff, the template has to be setup correctly, which will be described in the rest of this post.