As you may or may not have seen by now, we’ve released the new Yahoo! Widgets/Konfabulator 4.5. This version was a major undertaking, and there are four particularly cool and important features in it for developers.

• HTML
• Flash
• Full W3C DOM
• Fine-grained Security

HTM… something or other

Yes, you can now embed HTML into your Widget, thanks to the magic of WebKit. If you wanted, you could pretty much write all of your Widget in HTML. You can also just grab some AJAX code off the web and with a few modifications get it running inside Konfabulator. Your HTML code has access to all the features of the Konfabulator engine if it’s all contained in your Widget bundle. If you are accessing remote sites or scripts, you are restricted to the typical web sandbox. Just add a attribute to your Widget and point it at an HTML file and you’re off! Not only can the HTML view see Konfabulator, but Konfabulator has access to the innards of the web view itself via the ‘base’ attribute of the web object.

Flash! Ahh-Ahhhhhhhhh!

After HTML, there’s Flash. Like HTML, you can deploy a Flash Widget in Konfabulator. If Flash is your favorite language, have at it. Unlike HTML though, Flash cannot access Konfabulator itself, but Flash does provide a number of its own useful functions to get things done. In theory you could write yourself a video-based-community-type Widget now

Both HTML and Flash run just as any other view inside your Widget. You can inter-mix them with other Konfabulator objects and control their opacity and rotation, as you’d expect.

Wait? What are you saying?

I’m sure many of you might be asking whether this means we are favoring HTML or Flash for writing Widgets. It does not. We are merely offering them as alternatives. Many developers want to deploy something in HTML to allow them to run a Widget on the Web. Now they can also get a desktop presence in Konfabulator without having to rewrite the code. The same thing applies to Flash. Would I recommend this way of writing Widgets for someone just starting to use HTML? Probably not. It’s way too heavy for most Widget needs - it will consume more resources for not a lot more bang on average. If you don’t require features specific to HTML, or you aren’t porting AJAX code, I still recommend you stick to the native language.

DOM, da-DOM DOM!

Another big change is the introduction of the full DOM. This means the entire structure of a Widget is now accessible via DOM APIs. You can even run an XPath expression across your Widget. Rob does this to find all elements with tooltips in one of his Widgets, for example. You can locate all your Windows simply by saying document.evaluate( “/widget/window” ). Simple. As you are developing, you can also look at your DOM by merely executing document.toXML() in the debug window to see if things are as you expect them to be.

Fine-Grained Security

The new release has an expanded Security Block. It’s enforced if your Widget has a minimum version of 4.5 or later. It lets you specify the things your Widget might want to have access to, such as the file system, http, etc. This information is shown to the user in the new security dialogs. The dialog can now be expanded to display the information in (hopefully) human-readable form.

If your Widget ventures beyond the contract of your security block, an alert is presented and your Widget is terminated with extreme prejudice.

Under The Hood

The DOM really caused us to change our entire infrastructure. This might cause some compatibility issues with some Widgets. For example, one of our own Widgets had a property of an object called tagName. This is unfortunately an official property of a DOMElement these days, and so there was a conflict and the Widget had to be fixed. So as you try your Widgets out on the new engine, be on the lookout for issues like that.

We also have a new JS engine in this release. It’s the first time we’ve upgraded SpiderMonkey since the original Konfabulator release, as far as I know. Like the DOM, this might also cause some subtle issues for your Widgets. One example we ran into with two Widgets in particular is that there’s a class called Block in the new JS, and these two Widgets tried to create their own variables called Block.

We ran about 1000 of the most popular and recently-added Widgets when we tested this version of the product. We fixed everything we found, and when we found something we couldn’t fix (like the issues mentioned above) we reached out to the developer of the Widget to tell them what needed to be changed so they could resubmit their Widget with the fix so that users could hopefully get uninterrupted service.

The good thing about this infrastructure change is that we now have an excellent, solid foundation on which to build. We can add features faster now than ever before. For example, our new Display object took me literally 20 minutes to add. Granted, it was a simple feature, but it would have taken hours previously. This is going to make a huge difference for us. It also means we can start to implement things we never could before.

With our infrastructure out of the way, the next releases are going to focus on features to allow developers to build some amazing Widgets faster and easier than you could in the past.

Bonus!

One other thing: there’s a rudimentary debugger accessible from the debug window now. It’s not 100%, but it’s a start. Eventually there’ll be a UI for it. /help should let you know what the commands are… it’s somewhat akin to gdb. I’ll likely post another entry explaining how to use it.

Until then, enjoy the new features!

Two months? Really? Well, less time blogging means more time working on cool things, and there certainly are quite a few cool things coming down the pipe! In the meantime, let’s talk developers. Some of this was covered at last month’s Developer Day, so those of you that were in attendance, keep the noise down in back there, youse (and if you weren’t able to make it, there’s some photos taken that day and a video of the Javascript talk that Douglas Crockford gave).

The 4.0

It’s been four months since Konfabulator 4.0 has been unleashed and it’s gotten high marks from users, developers and the ol’ blog-ball (”blogosphere”? Oh no, I’m not saying that). New Widgets have been released that take advantage of 4.0’s features and we’ve seen quite a few existing Widgets updated too. If you’ve got Widgets from 3.x or earlier that you haven’t cracked open in a while, now’s the time! At the very least, you want to be sure that you’ve got an icon for your Widget to stand out from the others in the dock.

The dock is a great way to display regular updates from your Widget, but even without going to those lengths, you can put a static 75×70 pixel image in your Widget’s metadata file to represent your Widget in the dock (and by doing so, avoid getting the generic icon). The path to your icon goes on the image usage="dock" line in your widget.xml file.

if you’re looking to have your Widget display periodic updates in the dock, a good way to start is to use the Widget Converter to crack open a few of the Widgets that ship with 4.0 and see the variety of ways in which they do it. Search the code for instances of widget.setDockItem( ).

Another good reason to add dock presence: icon-less Widgets aren’t eligible to appear in the Gallery Spotlight!

The Gallery

Along with 4.0, the Widget Gallery saw some changes too (though just the tip of the iceberg for what’s planned). The major change was the addition of the in-page installer. No more downloading a Widget, finding the downloaded file, unzipping/mounting a disk image, moving the Widget to your Widget’s folder, disposing of the downloaded file and then finally running the Widget. With the in-page installer, it’s a single click from seeing a Widget in the Gallery site or the Gallery Widget to having it on your computer and running.

To work with the in-page installer, Widgets have to be submitted to the Gallery as a .widget file. Zipped Widgets or Widgets saved on Mac disk images will no longer be accepted (an exception for Widgets that need to be zipped with supporting software, though those won’t work with the in-page installer).

If you have Widgets currently in the Gallery that were uploaded as .zip or .dmg, you’ll make them available to the widest audience by resubmitting them as a .widget file (and could take that opportunity to add a dock icon in there too!) Like those not having an icon, Widgets that aren’t in a .widget format can’t be selected for the Gallery Spotlight either.

Widgets also need to have a unique identifier. This is the <identifier> line in your widget.xml file. Widgets submitted to the Gallery with an identifier already in use — by any other Widget in the Gallery — will be rejected. Having an identifier will allow your users to be notified via the dock when updates to your Widgets are posted (on that not-too-distant-future day when the switch is thrown on that feature). If you don’t want your Widget to give automatic update notices, don’t include a <identifier> line in your widget.xml file.

An easy way to generate unique IDs is to use the UUID Vault Widget. An easy way to get a Widget rejected is to copy the com.yahoo.widget... value from an existing Widget. Don’t make me come over there.

The Unix Utilities

For the same reasons that Widgets in Zip or disk image archives aren’t being accepted in the Gallery, Widgets that make use of the Unix utilities will also be rejected. The utilities are just too large of a stumbling block for end users to get your Widget.

Most of the functionality of the Unix utilities has been added to Konfabulator itself, and if there’s something you’re using that we’ve missed, please let us know. This isn’t to say you can’t make use of Unix functions on the Mac and DOS tools on Windows, but you’ll have to use platform-specific code blocks for those tasks in your Widget instead of relying on the presence of the Unix utilities on Windows (and Widgets that aren’t cross-platform make Geary cry).

The Workshop

Lastly, a couple new items have been added to the Workshop if you haven’t stopped by recently.

The Widget badge creator is a simple way to make a badge for your site or blog for people to download your Widgets (or other Widgets that you like). Soon, this badge will use the same in-page installer as the Gallery so that people can get your Widget directly without leaving your site!

The Widget class library contains an extensive set of interface elements and the code to drive them, ready to be included in your Widget. It can save you a lot of time by not having to reinvent the wheel to get standard window, checkbox, drop-down menu, etc behaviors.

It’s about time for some tips and tricks, and today’s post is all about using the debug window more effectively.

Evaluate!

In 4.0.3 and later, we’ve changed the debug window’s evaluate field to actually do what it says now: evaluate. Pretty clever (read: about time). So for example, where you used to type:

print( x )

You now type:

x

Think of all the saved keystrokes!

Hidden Commands!

During 4.0, I ended up adding some commands into the debug window for my own nefarious purposes. I just didn’t put it into the /help command. They are:

/mem Reports the memory used by JavaScript itself. Note that this is not the memory used by the application as a whole. It’s generally fairly small.

/gc Forces garbage collection to happen immediately, prints the final memory number. Again, this is the memory used by the JS engine, not by the entire application.

/tracethrow [on|off] Allows you to see what the file and line number is as an exception happens.

Secret Functions!

One of the most useful functions you can use is _dumpViews. You use it as such:

_dumpViews( windowVariable )

You’ll end up with a nicely formatted list of views in the specified window. This is helpful if you don’t understand why things aren’t visible, etc. I use this all the time to help debug engine oddities.

A sample output might look like:

Window 010AEB30 d:0
View (010AEE18): (0 0 100 200) d:0 z:-1 v:1 o:255
Image (01091910): (0 0 140 140) d:0 z:1 v:1 o:255 image001 src: Sun.png
Image (01091AB0): (0 0 140 140) d:0 z:2 v:1 o:255 clipped src: Sun.png

In the output, there’s many abbreviated terms. ‘d’ means dirty, and is used internally for drawing. ‘z’ is the z-order of the view. ‘v’ means visible and should be 0 or 1. ‘o’ is the current opacity from 0 to 255.

That’s all for this time around. Hopefully the above items will help you debug your Widgets more effectively.

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”)

Except not in this case. The niftiness of the engine (imnsho) continues its upward trend.