For several months I’ve been meaning to build a Dashboard widget. There are several reasons for this endeavor – First, learning new tools and languages is a hoot. Second, widgets are your friend and won’t be going away anytime soon (read, it’s always good to keep up with technology). Finally, I’m all about sharing interesting code, tips and tricks through collaborative (open source) development. Read on for more about that last point.

I plan for this to be an on-going series, with each new post offering a new version of the widget. With each new release I will include all code in the form of a Dashcode project, which will offer a means for you to import the project, poke around to better understand how to build widgets and modify the code as you see fit. Future releases (and the accompanying blog post) will include descriptions, code snippets, screenshots and videos (screencasts) demonstrating concepts from visual layout to code examples to debugging.

Version 1.0 looks as follows, it’s quite simple, from both the feature perspective and development point of view – an image across the top, a listing of recent blog posts, and an option to get more information (clicking the little in the lower right flips the widget to show the reverse side).

I want this to become a community built widget. I’ll run with the first few releases, however, to take this widget to the next level here are a few things where I would welcome some expertise:

• Artwork for a logo (see the Top 50 Widget List for some nice examples)
• JavaScript / Dashcode expertise to help create unique & interesting functionality

All contributors will be acknowledged on the back of the widget. For example, as of release 1.0, the flipside looks as follows:

Depending on how this project progresses, and the support I can rally around extending the widget, at some point it may make sense to move this to Google Code as a community project. We’ll worry about that another day…

Without further ado, let me introduce the inaugural MacDevTips widget. The files included in the 1.0 release:

• MacDevTips Widget
• Dashcode Project File

You have two options to give the widget a try:

1. Install the widget on your Dashboard (download, unzip and double-click the widget)
2. Run the widget from Dashcode (download, unzip, open and run the project within Dashcode)

In the next post on this widget I’ll demonstrate through a screencast how I created the widget in Dashcode. I’ll also bump the release to 1.1 by adding code to resize the widget.

It’s always good to have a goal, and for this widget I think we should shoot for landing in the top 50 of the Apple Dashboard Widget repository. With the right mix of features and an open source approach to enable others to learn/build widgets, I have no doubt we’ll reach that goal sooner rather than later.

If you’d like to get involved in building an upcoming release of the MacDevTips widgets, drop me a note and we’ll get things rolling!

The typical use of diff from within a terminal (using the default Bash shell) is to compare files. However, with a little slight of hand, known a process substitution, we can use diff to compare the contents of two directories.

The syntax looks as follows:

<(commands)

>(commands)

Commands represents a single command (such as find) or a piped list of commands. The end result of using process substitution is that the commands act as a file. In the first example, the process substitution results in what looks like a file that can be fed into another command. The second example is the opposite, the process substitution enables one or more commands to act as a file for input. Let’s look at how we can use process substitution for comparing directories.

Let’s say we want to compare the contents of the two directories above. The screenshot was captured from Finder, and in this case, provides a concise view of each directory. However, if the directories are not as conveniently located (in the same sub-directory) or have many more files, or if you need to compare directories from within a terminal, then you could run the following from a terminal:

$ diff <(find tmp1) <(find tmp2)

Here we use the find command to walk through the directories. Using the process substitution, the results of the find command look as though they are files, which enables us to feed both into diff.

You can learn more about process substitution on the Bash man page at the Apple Developer Connection.

The HTML bundle in Textmate offers a wide selection of features for formatting, working with tags and previewing within a browser. One of the options that offers great mileage is Insert Open/Close tag with Current Word. If you have been working with TextMate and HTML for any length of time, this tip won’t be new. However, if you are new to either, I think you’ll find this little trick quite helpful.

The tip is all about working with tags, essentially offering an automated means to insert matching tags and intelligently placing the cursor based on the tag type. Once you get used to using this trick, you’ll spend a lot less time trying searching for that unmatched tag in your source, resulting in valid HTML the first time around.

---

The music in the video is J.J. Cale and the song: Call Me the Breeze.
A longer clip of J.J. Cale jamming: [audio:/2008/jj.mp3]

Click the image to see more about about JJ and the CD (at Amazon)

If you’ve ever bumped into a Microsoft Compiled HTML help file (the giveway is the .chm extension) and resorted to starting up a virtual machine in order to run an instance of Windows to view the file, there’s a better way…a chm viewer for Mac OS X.

Chmox is an open source application that displays chm files on Mac OS X. Viewing a file using chmox is as simple as downloading and extracting a dmg, pointing at a chm file and you are good to go.

Chmox is written in Cocoa (Objective-C) and uses both WebKit, and chmlib. If you are looking to dig a little deeper into how to work with chm files, Matthew Russotto’s site is also worth a visit. Matthew has included information on the chm file format, which you can find here.

A good way to learn more about how chmox works is to spend some time viewing the source files, which you can peruse on the chmox project at sourceforge.

I recently bumped into a clever tool for soliciting debugging help. Pastebin is a web-app where you upload a snippet of code for others to review. Viewers can makes changes and suggestions to the code in a separate window. There are some handy features including syntax highlighting and the option to callout specific lines of code.

Here’s how it works. First, you paste a block of code into a textbox, and choose the language for syntax highlighting. Enter a name and click Send.

\

Here is what the code looks like once uploaded to Pastebin.

Pastebin generates a URL that you can use to point others at your code block. People can make suggestions on your code, including calling out a specific line using @@. See the example below where I entered a comment and made a minor code change.

Once the change is saved, Pastebin updates the code block to look as follows:

One additional trick you can do with Pastebin is create a sub-domain for your own specific debugging needs. For example, if I type in http://macdevtips.pastebin.com, I get a private area for working with code snippets. This area is still viewable by anyone (who knows or guesses the sub-domain), however, posts are not shown in the “Recent Posts” section at the homepage of Pastebin (it’s easiest to understand by simply giving it a try).

Pastebin is a nice tool when you need another set of eyes to look at your code.

As explained on the previous post, no doubt there is a means to capture a screenshot of the login screen, including all available user names. The question is, how to get there from here? Brett on the Cocoa developer mailing list provided a link to OpenGLScreenSnapshot, which is a Mac OS X application that demonstrates how to use OpenGL to grab a snaphost of the screen and save it to an image.

The example is an Xcode project which is easily imported and ran from with Xcode. The only problem is that the short example uses a menu to invoke the screencapture, so there is no means to logout and invoke the application.

I imagine the code change to make this an application that can be run from a terminal (at which point it could be run in the background using sleep) is trivial. However, problem is, I haven’t spent any time working with Xcode so it may take some time to figure this out.

Needless to say, it’s been an interesting challenge to try and capture the login screen. As I mentioned before, I think we’re 99% of the way there and if anyone can take the above example and make a command line version of the application, who knows, maybe that will bring this thing full circle.

It’s been a great diversion. So what’s the next challenge we can take on ?

In Part 1 of this series I described my attempts to get a screenshot of the login screen on Mac OS X. The attempts included using hotkeys, Grab application, fast user switching and putting the system to sleep and using the terminal utility ‘screencapture.’ All to no avail. The real challenge at hand is that I am looking to accomplish this feat from just one Mac system.

There were several ideas shared by others, including using cron, apple remote desktop and ssh. Again, good intentions, however, no luck.

I was able to dig up one approach that get that gets us 99% of the way there. From a terminal, I can enter the following, where I specify the login name using the switchToUserID parameter:

/System/Library/CoreServices/”Menu Extras”/User.menu/Contents/Resources/CGSession -switchToUserID `id -u root`.

The last parameter `id -u root` uses the terminal command id to convert a user name to a number. Upon running this command, a login window is popped up for the login id specified, see the figure below.

If I change the login id to another user, the login window changes as well:

The 1% that remains is that what I really hope to capture is the login window where all available login ids are shown.

There is a related command (below) that displays the login window I am after, however, this brings me back to the same problem I started with, that is, no means to get a screenshot.

/System/Library/CoreServices/”Menu Extras”/User.menu/Contents/Resources/CGSession -suspend

With some further digging I was able to successfully get the screenshot that I’m after with a couple of approaches:

1. Using a screen recording program such as ScreenFlow: enable fast user switching, start the recording and select the login window option from the fast user switching dialog. This will capture the sequence of events including the elusive login window.
2. I also found a few screenshot applications that can successfully capture the login window while running in the background. For example, Christian at MonkeyBread Software wrote a freeware application in REALbasic TimedScreenshot (here’s the source code) that will capture the screenshot I am after:

So, it’s obvious we can get there from here. The question that remains is, what system level API/library can we call to make this happen?

Ideally I’d like to have a very simple application, written in as few lines of code as possible, using tools that are freely available (e.g. Xcode or even better, just terminal commands). If this involves running a program in the background using a terminal command such as sleep (as I did with screencapture in the previous post), that works for me.

Any developers (Cocoa or otherwise) who can take this challenge the last mile?