Creating Widgets
with Dashcode
Volume Number: 24 (2008)
Issue Number: 08
Column Tag: Dashboard Widgets
Creating Widgets
with Dashcode
When to use Dashcode, and other
important widget information
by Mihalis Tsoukalos
Introduction
This article is going to introduce you to Dashcode, an application -actually, an IDE- for creating and debugging Dashboard Widgets. You will also learn other essential information about installing and packaging Widgets, the Info.plist file and its keys as well as the Property List Editor.
What is Dashcode?
Dashcode is a development environment, a GUI application, for creating Widgets. Although it was exposed prior to its official release, we now know it is a reality. With the release of Mac OS X 10.5 and Xcode 3, Dashcode was officially released to end users.
You should use the Xcode Tools installer to install Dashcode. After installation, you will find Dashcode in /Developer/Applications/.
Figure 1 shows the About Dashcode window information of both the unofficial-this beta expired on July 15th, 2007-and official versions. Both versions are numbered as 1.0!
Figure 1: The "About Dashcode" information window
of the unofficial and official Dashcode versions
When to use Dashcode
- Dashcode is a great tool but it cannot solve every problem efficiently. Knowing its strengths and weaknesses will help you use it effectively. You can also judge when, and when not to use it.
- Dashcode is wonderful for automatically creating template files that you can edit, as you wish, when creating your own Dashboard Widgets. This is a great time saver!
- Dashcode is perfect for debugging Widgets because it allows you to dynamically view your errors. Another great time saver when troubleshooting Dashboard Widgets!
- Dashcode is useful for quickly creating Info.plist files.
- Dashcode is very efficient when creating Widget with localization.
When not to use Dashcode
I'll first admit a little bias: I personally do not, for the most part, like integrated programming environments, as I prefer to write my own code using my editor of choice. Although Dashcode came into action while I was writing my eBook, I was very happy that I wrote most of the book's code using an editor without using code that was automatically created by a tool. I dislike the fact that most programming environments style code as they prefer, where they prefer and, sometimes, without letting the programmer decide essential details.
My advice is that when you are learning a new programming paradigm or technique, it is generally better to first write all your code by hand, and, as you become more experienced, to use such a tool. Through exerience, you can differentiate good code from bad code, debug your code and make changes to the created code.
Also, although Dashcode allows the use of Widget plug-ins, it cannot create Widget plug-ins. You still need Xcode when programming Widget plug-ins.
If you create a Widget using Dashcode, your Widget will look similar to other Widgets created using Dashcode-so originality is not easily achieved.
How to package a Widget
Let us say that you have a minimal Widget, called HelloWorld-it just displays the "Hello World!" message inside Dashboard. This Widget only needs four files named HelloWorld.html, Info.plist, Default.png and Icon.png. The last three filenames are fixed, whereas the first one can be anything you want-provided that it is an HTML file-but its filename should be declared inside the Info.plist file.
So, you have your files and you want to actually "create and use" your Widget.
All you have to do now is put all the above files in the same directory. It is a good practice to use an explanatory directory name. I called mine HelloWorld. The next action is to go to the parent directory of the HelloWorld directory in order to rename it. The new name will be Helloworld.wdgt. A message asking you if you are sure about the new extension will appear and after answering yes you will get your first Widget ready for installation! The sign that you have successfully changed the directory type is that the directory icon will change.
Most of the time, it is good practice to have a copy of your Widgets as plain directories that contain the relevant files. It makes watching and changing the files easier as well as serving as a backup copy. Figure 2 shows the Command-I (using the Finder) information for a Widget bundle and the relevant plain directory structure, respectively.
Figure 2: The Cmd+I output for the HelloWorld.wdgt bundle and the HelloWorld directory
Installing a Widget
There are two places that you can install a Dashboard Widget. Also, there are two ways for installing a Widget.
The first place for installing a Widget is in the /Library/Widgets directory. The Widgets that are located there are system wide, which means that everyone in the same Tiger/Leopard system can use them. The second place is inside the Library/Widgets directory that is located in each user's home directory. Your home directory is usually called /Users/your_user_name.
The first way to install a Dashboard Widget is to double click on it. Mac OS X will ask you if you want to install it and if you answer "yes", it will put the Widget inside the Library/Widgets directory on your home directory. This directory is also called -given the shorthand notation- ~/Library/Widgets, with the tilde signifying your home directory in the UNIX jargon. This means that other users of the system cannot automatically use your Widget.
When double clicking a Widget, a message will ask you if you want to install it (this happens for security reasons). By pressing "Install", you will go inside Dashboard and see Figure 3.
Figure 3: Trying to install the HelloWorld! Widget
If you answer "Keep" the Widget is going to be installed inside your home directory ~/Library/Widgets. If you answer "Delete", the Widget is going to be placed in the Trash.
The second way is to manually copy the Widget bundle inside your preferred directory. You can still put in inside the Library/Widgets directory in your home directory (a.k.a. ~/Library/Widgets) but you can also install it manually in /Library/Widgets, provided that you have the required administrator privileges.
The Info.plist file and its keys
The Info.plist file is the property list file for every Dashboard Widget that is a XML file. Its filename is mandatory as well as its presence inside each Widget directory (or bundle if you prefer). The Info.plist file contains some keys, five of them being obligatory. Other keys may or may not be defined depending on the resources that are needed to be utilized by the Widget.
The mandatory property list keys are the following: CFBundleName, CFBundleDisplayName, CFBundleIdentifier, CFBundleVersion and MainHTML. All of them are of string type. The required properties are displayed in bold type in this list:
AllowFileAccessOutsideOfWidget: This key defines if the Widget is allowed to access the file system that is outside the Widget's directory. Access is limited by the permissions of the user that runs the Widget.
AllowFullAccess: This key defines if the Widget needs access to file system, Web Kit and standard browser plug-ins, Java applets, network resources, and command-line utilities.
AllowInternetPlugins: It defines if the Widget requires access to Web Kit and standard browser plug-ins.
AllowJava: It defines if the Dashboard Widget needs access to Java applets.
AllowNetworkAccess: This key defines if the Widget needs access to resources that are not file-based, including network resources.
AllowSystem: This key defines that the Widget requires access to command line tools using the Widget script object.
BackwardsCompatibleClassLookup: It defines if the Widget uses the JavaScript classes that are provided by Apple in a backward compatible way.
CloseBoxInsetX: It defines the offset for the location of the Dashboard Widget close box on the x-axis. Allowed values are between 0 and 100.
CloseBoxInsetY: It defines the offset for the location of the Dashboard Widget close box on the y-axis. Allowed values are between 0 and 100.
Font: It defines an array of strings. Each string denotes the name of a font that is located inside the Widget's root directory.
Height: It is an optional number that denotes the height of the Widget in pixels.
Width: It is an optional number that denotes the width of the Widget in pixels.
MainHTML: The relative path to the Widget's main HTML file. If this is wrong, chances are the Widget is not going to work at all!
CFBundleIdentifier: This is the "unique" name of the Widget. Apple's Widgets are named com.apple.widget._widgetname_ }. Other Widgets are named similarly.
CFBundleName: A string that defines the name of the Widget. The string must match the name of the Widget directory on disk without the .wdgt file extension.
CFBundleDisplayName: A string that defines the text that is going to be displayed in the Widget bar and the Finder.
CFBundleVersion: This is a String that defines the exact build version of the Widget.
Plugin: It is a string that defines the name of the custom plug-in that is used by the Widget. Plug-ins are located inside the Widget's directory and are compiled Objective-C code.
The list is big but, as you already know, only five property list keys are mandatory. Most of them are optional, depending on what your Widget is planning to do. It is a very important task to define them the right way-both for security and functionality reasons.
It is important to remember that if your Widget does not work as expected or does not even show on Dashboard, the first thing to look is if the required property list keys are properly and correctly defined. It is a common mistake that can cause a lot of lost time in debugging.
The Property List Editor
The Property List Editor is for creating, altering and viewing an Info.plist file (and other .plist files) which is a plain text file in XML format. The main difference from a text editor like vi, emacs, or nano is that Property List Editor is a GUI application-some people find it easier and less error prone to use a GUI application than a traditional text editor. On the other hand, plain text editing is quicker and can be automated using a scripting language.
Be careful with the editor you use, as not every application saves in a plain text format. Be aware of software such as Microsoft Word for Mac or Macromedia (now Adobe) Dreamweaver to create a pure text file.
First, let me present you an example Info.plist file in XML format:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple Computer//DTD PLIST 1.0//EN"
"http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>AllowSystem</key>
<true/>
<key>CFBundleDisplayName</key>
<string>MakeTar</string>
<key>CFBundleIdentifier</key>
<string>com.mtsouk.widget.maketar</string>
<key>CFBundleName</key>
<string>Make Tar Widget</string>
<key>CFBundleShortVersionString</key>
<string>1.1</string>
<key>CFBundleVersion</key>
<string>1.1</string>
<key>CloseBoxInsetX</key>
<integer>45</integer>
<key>CloseBoxInsetY</key>
<integer>35</integer>
<key>MainHTML</key>
<string>MakeTar.html</string>
</dict>
</plist>
The same Info.plist file in Property List Editor can be seen in Figure 4.
Figure 4: A Property List Editor example
Apart from the preamble of the Info.plist file, which is hidden in Property List Editor, the rest of the information is easy to be seen or altered. If you press the "Dump" button in the upper right corner, you will get the Info.plist in plain text format, including the preamble.
If you ask my opinion, I prefer the plain text version of the Info.plist file :-) I rarely use the Property List Editor.
A Dashcode example
This part of the article will present you with a brief Dashcode example. I am going to create a complete Widget, for illustrating the Dashcode usage. In a previous article, I created a Widget that reads the RSS feed from MacTech.com and displays it in a Widget. I decided to create the same Widget using Dashcode. Please note that there is an existing RSS feed Widget template inside Dashcode that greatly simplifies the process.
Figure 4 shows the look of the Widget created in Dashcode. You can also dynamically change the length of the presented articles (using the backside of the Widget)-I should say that I am pretty impressed as it only took me 10 minutes to create it! It is also impressive that I did not write a single line of code!
Figure 5: A Widget that reads RSS feed from MacTech.com
When launched, Dashcode presents a theme chooser. There are two RSS feed types: a generic RSS list type, and a "Daily Feed" template. The "Daily Feed" template shows only the current item from the RSS feed. I chose the "RSS" template for this example (see below).
Apple's available Widget templates
Once chosen, Dashcode displays the main window with a graphical representation of the widget showing. By choosing "Widget Attributes" in the navigation bar on the left of the window, you can access and edit all properties of the widget. Figure 6 shows this screen, including the source for the RSS feed as well as some of the keys in the Info.plist file, the Widget identifier, its version number, etc. You can even add localization to your Widget.
Figure 6: Setting attributes from within Dashcode
For more complex widgets, or just for a little hand-holding, you can also follow the "Workflow Steps" portion of the window to step through the process. If an attribute is required, Dashcode lets you know with a "Required" badge.
For the RSS widget, only two attributes are required: the Identifier, and feed property. The identifier differentiates one widget from another. Typically, identifiers are specified in reverse domain notation.
In this example, the identifier is com.mtsouk.widget.sampleRSS. The version number helps Dashboard to determine if you're running the latest version of a widget. The identifier and version fields correspond to the CFBundleIdentifer and CFBundleVersion in the widget's Info.plist file.
The other required property is the FeedURL and respective feed information.
Then, by going to the File menu and selecting "Deploy Widget" (figure 10), you can export your Widget and have it as a separate object that you can distribute and install. After installing the Widget in Dashboard, it worked without problems.
Figure 10: Deploying a Widget from Dashcode
I will also show you the list of the files that Dashcode creates at the root of the widget package using the UNIX ls -al command:
mtsouk$ ls -al
.:
total 64
drwxr-xr-x 13 mtsouk staff 442 Apr 7 17:36 .
drwxr-xr-x 24 mtsouk staff 816 Apr 7 17:36 ..
-rw-rr 1 mtsouk staff 4329 Apr 7 17:07 Default.png
-rw-rw-r 1 mtsouk staff 1196 Sep 24 2007 Icon.png
drwxr-xr-x 14 mtsouk staff 476 Apr 7 17:04 Images
-rw-rw-r 1 mtsouk staff 832 Apr 7 17:36 Info.plist
drwxr-xr-x 9 mtsouk staff 306 Apr 7 17:04 Parts
-rw-rw-r 1 mtsouk staff 1840 Sep 24 2007 SafariStyle.css
-rw-rw-r 1 mtsouk staff 4084 Apr 7 17:07 SampleRSS.css
-rw-rw-r 1 mtsouk staff 3015 Apr 7 17:36 SampleRSS.html
-rw-rw-r 1 mtsouk staff 31187 Apr 7 17:04 SampleRSS.js
-rw-rw-r 1 mtsouk staff 295 Apr 7 17:24 attributes.js
drwxr-xr-x 4 mtsouk staff 136 Apr 7 17:08 en.lproj
True to my preference for hand coded widgets, I'll point out that the Widget I created for processing the MacTech.com RSS feed for the previous article is a little bit smaller in size.
Conclusions
Creating Dashboard Widgets is easy provided that you know some basic things and follow some principles. Apple provides many tools that will help you write Widgets. One of them, Dashcode, is a handy tool provided that you can understand its strengths and weaknesses. If you are an intermediate to experienced Widget programmer then it can save you time. If you are just starting Dashboard Widget programming then I would propose that you start programming Widgets without using Dashcode to truly learn the foundations of what goes into a widget.
Bibliography and References
http://developer.apple.com/
http://developer.apple.com/tools/dashcode/
http://www.apple.com/macosx/developertools/dashcode.html
Introducing Dashcode: http://developer.apple.com/leopard/overview/dashcode.html
Wikipedia Dashcode entry: http://en.wikipedia.org/wiki/Dashcode