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:

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” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”t be new. However, if you are new to either, I think you” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”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” onclick=”return TrackClick(”,’javascript%3AlynkVideoPop%28719%2C’)”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:

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.

Well, I haven’t given up on the mission to determine how to capture a screenshot of the login screen in Mac OS X. Read more here. In fact, I’ve been able to create a popup login window with a user name and capture a screenshot, however, it’s not exactly what I’m looking for. More to come…

In the meantime, I want to share a tip if you tire of email messages in iMail where the body of the message has been created in rich text. I’ve got a trick for you to turn email that looks like:

to email that looks like this:

Ah yes, good old plain text. Here’s the trick, from a terminal type the following:

defaults write com.apple.mail PreferPlainText -bool TRUE

That’s all there is to it. And of course, if you change the TRUE to FALSE, you’ll be back in the world of colorful, formatted messages.