Hey all! Fancy that - this is my first post on this newfangled Internet-type journal!

I should probably introduce myself. I’m the guy that basically runs the Widget Gallery - I manually go through each and every Widget submission to make sure that the Widgets are safe to run, and I take screenshots and post Widgets for download. I have other much more interesting responsibilities here on the Widgets team as well, but for the sake of being concise, I won’t go into them here.

I have an important change that pertains to you Widget developers out there, so listen up!

One of our top goals for our upcoming (dare I say imminent?!) Widget Engine release is to enable our authors to distribute their Widgets as easily as possible. That’s going to mean a lot of cool things, including a much lighter-weight installer. In order to do that, we’re removing the set of UNIX utilities that comes bundled with the Windows version of the product.

These UNIX utilities come from a long while back, when there weren’t as many commands available in our API. However, over the last several versions, we have added more and more native replacements for these utilities… and we will have replaced nearly all of them in the next version (and no, I unfortunately can’t tell you when it’s coming). So, in exchange for shaving several megabytes off the installer and adding some cool new features to make your Widget easier to distribute, we’re asking those of you who are currently using these UNIX utilities in your Widgets to make some minor changes.

As mentioned, there are a number of replacements already available in the API, which I’ve listed below. If your Widget is currently using any of the UNIX utilities that have a replacement listed below, you have two options: 1) use the native replacement; or 2) bundle the required UNIX utilities with your Widget. Effective immediately, anyone submitting a new or updated Widget to the Gallery that uses one of the below listed UNIX utilities will get an email back reminding them of these impending changes. Then, starting the Monday after next (January 29) (February 5), any Windows or cross-platform Widgets using UNIX utilities (from the current Widget Engine installation) in lieu of a native API solution will not be accepted for public download in the Widget Gallery.

If you are using one of the UNIX utilities that does not yet have a native replacement, keep in mind that a similar process will take place when we ship the next release. Of course, if you’ve got a Widget already in the Gallery that uses the UNIX utilities, it’s not going to break. We are committed to making sure that all of our upgrades are backwards compatible (within reason), and the existing features and functionality for these Widgets will continue as is. However, we strongly encourage you to update these older Widgets to take advantage of all the cool new things that will be available soon.

Here’s the list as it exists with the current version of the APIs. Check out the Yahoo! Widgets Reference Manual for more information on these different items.

• cat = filesystem.readFile( );
• cp = filesystem.copy( );
• curl = URL or XMLHttpRequest objects
• date = Date object (see the Mozilla Core JavaScript documentation)
• find = filesystem.getDirectoryContents( );
• ls = filesystem.getDirectoryContents( );
• mv = filesystem.move( ); (Note - Cannot yet be used to rename files)
• open = filesystem.open( );
• sleep = sleep( );

If you throw in a system.platform check to make sure you’re on Windows, you can use a couple of Windows shell commands in place of the UNIX utilities:

• rm = rmdir for folders, erase for files
• mkdir = …mkdir

Thanks for your time, and thanks in advance for your help in ensuring a smooth transition away from our UNIX utilities. Oh, and for you non-techie types: I apologize for the dry content of this post.

Ricky (aka “Widget Boy”)

The Widgets/Konfabulator team is upsizing!

If you’d like to help us out, or know someone who can, feel free to point them our way. We need help on our engine, as well as a Widget builder to help us build some cool, fun Widgets. Here’s some links to the two positions:

Widget Engine Engineer

Widget Builder

This is a great time to come on board and help out, as we’ve got some amazing plans for our future!

You know that icon attribute in the Widget XML?

Start using it.

Already using it? Well make sure you’re actually using it to reference an image that represents an icon, not a miniature screenshot of your Widget or other unrelated thing that may or may not have anything to do with your Widget. Having an icon there will be very important in the next release or two.

Here’s another tip to get an edge up on something even before we do… in the Widget icon template, I have the word “widget” on the face on the icon. If you’re on a Mac, you’re lucky enough to see all the great icons I’ve done for all the Widgets that ship with the product… they all have the word “widget” on them. That’s going to go away. So if you’re making a Widget icon now… ditch the word layer.

The curious are wondering what the story is. Well let me tell you.

On the Mac, when I first did the Widget icon, it was a UI convention to add the name of the file type to the icon itself. As the years passed, this held true, but only in a situations where the application had multiple files types, but the same document appearance.

Sure we have two file types*, but the .kon file type looks like a document, while the .widget file type looks like something unique. Plus, get a folder (or some other organizational tool) full of these icons, and it become ridiculous to see the word “widget” over and over. (Note that I keep putting “widget” in quotes because it’s lower case on the Widget icon, and when I write the word Widget, I always capitalize it.)

So there you go. Make use of that XML tag, and make use of our Widget icon template. You’ll be glad you did.

* Actually there’s a third type we never exposed and probably doesn’t even work on Windows. It was for a proprietary encrypted image format we’d created because I was tired of people ripping off my weather images. This was a great idea, but then common sense hit me and I pointed out that all someone had to do was make a Widget that only displayed a single image then take a screenshot of it.