What I continuously learn is that I really didn’t know the DOM spec like I thought I did. There is a lot of subtlety in the language that isn’t quite clear until you finally live the life for yourself. Over the weekend I was trying to get some stuff straight in my head. After working through it and getting my head around how to organize things, I was reading the W3C spec and noticed that it had basically said what I had just realized all along. It’s not super-obvious unless you really know a DOM implementation inside and out and have had to understand the design out of necessity. It’s a bit akin to my experience in karate where you’ll have someone tell you things a million times and then once you do it a zillion times you finally get it and say “my god, they’ve been telling me this all along”. There’s so much about learning that’s about experience and not words.

But of course the good news is that our DOM is much cleaner now and can be used for more things. I still need to figure out if I want to switch to use an Interface idiom ala Mozilla. It would simplify some things, but complicate others. More to think about. If I do go with Interfaces, I’ll probably just rely on C++ and not go so far as to use something like xpcom internally. That seems a bit much. But if I do C++ for now, it should be relatively straightforward to switch later if for some reason a COM-like solution was needed.

By far the trickest part is going to end up being how we expose things via Javascript. I’m not happy with the amount of work we have to do to expose a class. Too much repetitive work. I guess if we did use xpcom it would be a lot simpler since xpconnect does all these things for you. But that is biting off way more than we can afford to chew right now. Phasing is critical to success long term. I do have a decent hybrid solution in mind that can bridge the gap from where we were and a completely generic solution such as xpconnect.

Once our new foundation is in place it’s going to make a huge difference in what we’re able to do and how quickly we can do it. A lot of doors are going to open up when I’m done. It’s going to be pretty cool. If only I could finish!

(I’ve badged the Flickr Widget over on the right as an example.)

You can get more information on the Widgets Blog.

I should point out that their Widget takes 26MB of RPRIV on Mac OS X, our Weather Widget takes 3MB. Booyah. Yeah, i know it’s alpha, but still.

Certainly the current attitude has been that they should be small mini-applications, and not try to approach the complexity of a full-fledged desktop application, such as a word processor or mail program. But really, where do you draw the line? If you look at our current FIFA Widget, it’s actually quite complex. It’s merely a data display device though… lots of data in a compact form factor. However, Something like the Yahoo! Address Book Widget has much more functionality: not only can you view your address book, but you can add and remove entries right in the Widget. Have we gone too far, or not far enough?

Certainly the current engine we have isn’t going to be used to write anything as thorough as something like Photoshop. But given time and resources, we could add the necessary support. The question of course becomes “why”. That’s what’s not clear. One of our goals has always been to make it very simple to dabble with writing Widgets. The more complex you allow the platform to become, typically the greater the barrier to entry becomes. I do think we have an advantage in that we don’t need to shoehorn what we want to accomplish into any existing standards, for the most part (though as time passes, we are attempting to use more standard idioms and names for things). This does allow us to have a very low barrier to entry while still allowing more complicated things to be done. And we do in fact have plans to make some of these complicated things even easier in the future.

Another point about going the full toolkit route: we could certainly add all the functionality in the world, but then we’re almost doing the same thing as something like XULRunner. I think for Widgets, XUL is too much. The sheer number of things available to use can make the simple hobbyist who just wants a server monitor balk. Do we want our engine to be that large and complex? If there is a line, that seems way over it. And since XULRunner (mostly) exists, it’s not clear that we’d even want to go down that road for our engine anyway.

So I think the answer is that at least for the duration, Widgets should remain small, lightweight, and quick and easy to put together. I still don’t know where to put that line, but I think we’ll have an idea when we’re up against it. When that happens, I’ll let you know

For users, there are all new Widgets that connect to Yahoo! properties (Search, Maps, Flickr, Y! Photos, Notepad, 360) and some significant fixes, particularly for Outlook users who used PIM Overview (now called Day Planner). It also brings some performance improvements, particularly on Mac. We were encountering problems with Cocoa’s lack of support for overlapping sibling views. Apparently the answer in the past was to just draw everything all the time. But that wasn’t flying so well these days with more complex Widgets. So I changed it to bypass the Cocoa view system and just use the same basic view system we do on Windows. We tried to layer it at first but we got some weird overdrawing issues with rotated items. Turns out eliminating the Cocoa draw path sped us up considerably (very user-perceptable in some Widgets such as Atomic Timer).

For developers, there is a whole new set of features: a native XML parser, Level 1 DOM support , XPath, XMLHttpRequest, subviews, scroll bars, and much more. The interesting thing is that I still have a whiteboard full of things we still want to do for the future. We’re hardly done making this platform as powerful as we want it to be.

Anyway, I’m very glad this is now out the door as we can start concentrating on some of the features I’ve been dying to do for some time. Things that will really up the ante for what you can pull off in a Widget. But first I must rest and do my Christmas shopping!