This post originated from an RSS feed registered with Java Buzz by dion. Original Post: Building a Desktop Shell around a Web page for Apple Mac OS X with Cocoa Feed Title: techno.blog(Dion) Feed URL: http://feeds.feedburner.com/dion Feed Description: blogging about life the universe and everything tech Latest Java Buzz Posts Latest Java Buzz Posts by dion Latest Posts From techno.blog(Dion)

As we use web applications more and more on core tasks (email, calendar, office) I have found that I sometimes get frustrated when some annoying piece of Flash on a random web page brings down my entire browser process (including the web applications that I care about).

Some browsers allow you to run multiple instances in their own world. For others you could hack around that by having multiple copies of the browser. I have gone through phases of compartmentalizing my work on various browsers.

• Development work on a Firefox instance because I want to use Firebug
• Fluffy browsing on WebKit nightly (to try to be a tester too)
• Apps in Safari

My main problem with this is that I normally also want Firefox for certain apps because I make heavy use of Greasemonkey. I couldn't do Gmail without at this point (let alone the other sites).

I am used to having my calendar on window 2 of VirtueDesktop (iCal). I am not experimenting with Google Calendar, and I want to do the same. Instead of just having an instance running Google Calendar over there, I decided to try to built a wrapper around a browser component.

I am trying this in both Mac OS X Cocoa, and Adobe Apollo.

Today we will discuss the OS X version.

In theory the hard work is definitely already done for us. The WebKit component is nicely done for us, and the documentation is thorough.

I decided to try to follow the "Multiple Windows" example:

You can implement multiple windows in a Web Kit application easily by beginning with a Cocoa document-based architecture as follows:

1. Using Xcode, create a document-based Cocoa application. Your new project file will already contain the needed classes and interface files to support multiple windows (namely MyDocument.h, MyDocument.m, and MyDocument.nib).

2. Add the Web Kit frameworks to your project.

3. Open MyDocument.nib using Interface Builder and drag a WebView from the Cocoa��GraphicsViews palette to your document window.

4. Create a webView outlet in MyDocument.h and read the file into Interface Builder. Connect the webView outlet of the File��s Owner to the WebView object you created in the previous step.

5. Add code to MyDocument.m to load a default page. You can add this code fragment to the windowControllerDidLoadNib: method:

   NSString *urlText = [NSString stringWithString:@"http://www.apple.com"];
   [[webView mainFrame] loadRequest:[NSURLRequest requestWithURL:[NSURL URLWithString:urlText]]];
   

As a newbie to Obj-C and Cocoa, a couple of these instructions were light.

1. Creating the project was simple. It wasn't hard to see 'document-based'
2. Adding the Web Kit framework was simple too, although it seems like there are several ways to skin the cat. I did Project - Add to Project - Find System/Library/Frameworks/WebKit.framework. Done.
3. I found the WebView pane and it was obvious to drag the component that looked like Safari onto the main panel.
4. I have never created an "outlet" before, so this took some time to play. I added IBOutlet WebView *webView; to MyDocument.h... but then how do you read it into Interface Builder? In some ways Interface Builder is great, but it was also a bit frustrating to work with. I felt like I was constantly looking to click on the right area to then be able to do things. E.g. most of the time "Classes - Read Files" was greyed out, until you click on File's Owner (from the Instances tab). Then, connecting the darn thing drove me nuts. I am not a mouse guy. I don't like to draw my applications. I wanted to select the WebView component that I created, and in connections let me select the webView variable that I just read in. The tool wouldn't let me. It kept saying "You need a component of type WebView". It was! Trying to manually connect was a pain until I worked out that it just needed a darn right click (ironic coming from Apple) to drag the connection from the "File's Owner" to the WebView component in the window. With that, the connection in the inspector showed up nicely. Why wouldn't it just have a drop down to show the ONLY COMPONENT out there that was of that type? Why make me draw?

After adding the code to point to Gmail as a test, I launched the app, and indeed a window showed up with the web page in it. Great! At this point we are pretty unusable though.

First, Gmail was showing me the 'basic' HTML view and telling me that I wasn't supported. At this point I had a couple of options. I could put in the hard coded URL to Gmail that says "do not check the browser, just show me the good ones", or I could change the User-Agent to tell people that this was indeed something decent.

To change the user agent you simply say:

[webView setApplicationNameForUserAgent:@"Safari/417.9"];

While you are there you probably want to setup nice title bar names and such via:

[webView setGroupName:@"Google Calendar"];

Window resizing and linkage

The app works great until you click on something or try to resize the window :) At this point it doesn't work. At this point we need to go through and set the sizing to allow for happiness, and to let link clicks target the view.

It was at this point that I remembered Michael McCracken had done a wrapper for Gmail back in time: "All it does is load Gmail in a nice big window and duck out of your way. No location bar. And no bookmarks."

I grabbed his code which had dealt with this, and tweaked it to work for my needs.

Downloads

If you fancy taking a look at the source, or just running Gmail or Google Calendar as a normal app that you can put in your dock, and live in its own process, download:

• GCal
• Gmail