After giving it some thought I think holding off is the wrong approach. I should allocate some resources to a side project. It will slow down the main project speed a little bit, but I think that this approach will increase the quality of the main project.

When doing web applications it was not uncommon to switch back and forth between projects on a bi-weekly basis. In doing so I would be disgusted with the “old” code when switching back to a project. I would then merge in changes and updates to shared code, modify things a bit to fit the “new” way of thinking. Basically all the ideas and knowledge I had acquired since working on this project would be merged back.

My brain never stops learning and growing so why should my projects stop as well? I am taking on a minor project that I will force myself to work on for a full day once a week. I am hoping that in doing so I will dig myself out of the hole one can do when spending too much time on one thing.

Sneak peak screenshots of the upcoming side project to be posted soon.

Here is a sneak peak at what is coming up.

Turkeys?

According to Apple’s developer documentation, the Settings application should be used in “productivity-style applications”.

Adding your application preferences to the settings application is most appropriate for productivity-style applications and in situations where you have preference values that are typically configured once and then rarely changed.

The documentation goes on to say that applications should not duplicate the functionality of the settings application, nor should they be used in utility style applications or applications with few preferences.

I think this is the wrong approach all together. This breaks application flow, and in many cases, preferences despite proper verbage, will not always be 100% clear. In some cases a user may want to switch a preference, see how the application’s functionality has changed then switch again.

There are also preferences that fall under the “set once” category and some that fall under the “depends on my mood” category. My favorite IM application Beejive IM suffers from this problem, preference schizophrenia. Take Beejive IM’s “More” tab.

Beejive IM

There are no settings in this tab, although, you can set the application’s wallpaper here. This is a good example of a setting that a user will try out quickly, but schizophrenia lurks around the corner. Clicking the Support tab brings up an FAQ. There is a question in the FAQ “Where are my settings?” that points the user to the settings application.

The settings application has a bit of a lag when loading in 3rd party applications, and because of this, coupled with it not being natural to change application settings outside of an application, I rarely notice these. When directed here looking for Beejive IMs settings I found settings to applications I was unaware had settings. Either I had checked here after installing it, and they were added in a later update or I just missed them altogether.

Application Settings

Inside the Beejive IM settings pages there are a ton of settings, some of which are closely related to the wallpaper setting that is located inside the application. Changing the wallpaper could make text unreadable, and require me to quit the application, change the color scheme from settings and relaunch Beejive IM and hope I do not have to repeat. “Status Icons” and “Table Divider” are both settings which I need more instant visual feedback to make a decision. When preferences are outside the application and I am not 100% certain how they work, I am less apt to play around with them.

Beejive IM Settings

Now do not get me wrong. From a developer stand point the SDK provides a really easy way to create preferences. The new file dialog has a “settings bundle” which creates a easy to edit and understand XML file. From there accessing the preference values is as simple as two lines of code (replacing “typeForKey” with the proper type int, bool, etc…)

NSUserDefaults *userDefaults = [NSUserDefaults standardUserDefaults];
[userDefaults typeForKey:preference_key];

It is obvious that Apple is trying to solve the issue of preference interfaces being horrendously designed as well as trying to keep everything in one neat and tidy location. Fixing the the issue of the user not being aware of preferences could be solved with a badge icon for updated settings bundles at application install time. This would notify the user of settings needing to be set, and get some of the first time settings out of the way. Apple’s own documentation says this area is for settings that will be touched once. The setting buttons for 3rd party applications should launch the settings pages in the application in question so as to alleviate the issue with switching back and forth and trying out settings.

TL;DR version
Disadvantages

• Breaks application workflow.
• Confusing to users used to desktop style settings.
• Hard to “try out” preferences quickly

Advantages

• Very easy for developers to implement.
• Attempts to keep bad settings UI design away from the user

Possible Solutions

• Badge notifications for updated / added 3rd party preferences when an application is installed or updated
• Settings part of the SDK allows for creation of a settings page collection that is viewed and accessed inside the application itself.
• Clicking the application from the settings application opens the settings pages inside the 3rd party application.

13
14
15
16
17
18
19
20
21
22
23

@interface WFTexture : NSObject {
    // Bitmap data
    NSBitmapImageRep *bitmap;
 
    // Bitmap information
    double width, height;
    GLenum pixfmt, bpp, datatype;
 
    // Texture ID
    GLuint textureID;
}

After reading thru this code a pattern emerged. I was creating objects for the sake of creating objects, instead of using objects to solve a specific problem. For example, why would I need to keep around the original bitmap data after it has already been offloaded to the GPU? To a lesser extent why would I need to keep around the bpp or pixel format of the data offloaded aside from out right wasting system resources.

I then started to look at the implementation which I will snip for brevity:

35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51

- (NSBitmapImageRep *) bitmap { return bitmap; }
- (void) setBitmap: (NSBitmapImageRep *) newBitmap
{
    [newBitmap retain];
    [bitmap release];
    bitmap = newBitmap;
}
- (float) width { return width; }
- (float) height { return height; }
- (GLenum) bpp { return bpp; }
- (GLenum) datatype { return datatype; }
 
- (GLuint) textureID { return textureID; }
- (void) setTextureID: (GLuint) texid
{
    textureID = texid;
}

The implementation makes me certain I was thinking too much about the object and not enough about the problem it is used to solve. Aside from being able to access various bits of information about the original image data (bpp, width, height, datatype) I created set and get methods for both the bitmap data and the OpenGL texture ID.

If this was supposed to be a reusable object giving access to setting the texture ID would have be atrocious. Instead of changing the ID, a whole new texture object should be created. Also take note that once the bitmap was set to something new, no OpenGL texture data was uploaded. If I was really bent on storing the bitmap data in memory as well in VRAM, then bent on allowing the changing of this bitmap data, the set method should at least re-upload the new bitmap data to the graphics card. But I digress.

The only bit of code I thought about snagging from this entire object was this:

136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154

- (void) on
{
    if ( width != height ) {
	glEnable(GL_TEXTURE_RECTANGLE_EXT);
	glBindTexture(GL_TEXTURE_RECTANGLE_EXT, textureID);
    }
    else {
	glEnable(GL_TEXTURE_2D);
	glBindTexture(GL_TEXTURE_2D, textureID);
    }
}
 
- (void) off
{
    if ( width != height )
	glDisable(GL_TEXTURE_RECTANGLE_EXT);
    else 
	glDisable(GL_TEXTURE_2D);
}

But I thought otherwise when I realized this code makes way to many state changes. Objective-C is very object intensive and you are rewarded for creating proper objects, but it makes it very easy to waste resources. Going over old code I wrote was a great learning exercise for me, and it drove home the point that I need to only write methods and properties as I use them.

Open source is great, but at the point where the licensing and patenting arguments get in the way of furthering computing I say screw it. Enough.

Basically it boils down to this: H.264 is the superior technical choice and logistical choice, while Ogg/Theora is the idealistic choice. Yes you can send me mail all day long about Theora can be just as grand looking as H.264 but out of the box support for H.264 is far higher. It is built into hardware and most modern operating systems ship with it.

To all those Stallmanites complaining that Apple has some devious plans: You are wrong. If you sold hardware that had built in support for a specific format, would you not stick with that format? Would it not provide the better experience to your users?

Ultimately it is about furthering computing, not waging some ideals war.