Being One with the DOM

Over the past couple of weeks, I’ve been doing a lot of work with our Konfabulator DOM. In some ways, we are completely redoing it so we can use it as the basis for everything (finally). I have also been looking at better ways to expose it via JavaScript.

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!

Badges of Honour

Yes, you can now put a badge on your website pointing to any Widget in the Yahoo! Widget Gallery by going to our Badgers page. You can point to any Widget you want, be it your own or your favorite. Badge away!

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

Developer Day!

We’re offering the first ever Yahoo! Widgets Developer Day at our headquarters in Sunnyvale, CA. If you happen to be a Widget developer, we’d love to see you there.

You can get more information on the Widgets Blog.

Yahoo! Widgets 4 Released

We’re done with Yahoo! Widgets 4! Read all about it on our official Widget Blog. This release took a while to get done, but the team is ramped up substantially. We do still have three engineering reqs. to fill, so if you know someone who’s a wiz at doing framework-level development, send them our way. The next couple of releases are really going to change things.

Hey! That ain’t right!

Check out this picture. On the left, Konfabulator/Yahoo! Widgets. On the right, an Apollo sample. As you can see, they stole our images verbatim. Not cool.

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.

What is a Widget?

An interesting topic came up in a meeting recently surrounding what a Widget is. What is it? Should they be small an extremely lightweight in functionality, or should you be able to write some moderately complex things with the technology? There is a continuum of possibility, but where should one draw the line? Should there be a line at all? (more…)

Yahoo! Widgets 3.0 Released

Yes, finally. Yahoo! Widget Engine (nee Konfabulator) was just released today. It’s a huge step forward both in end user benefit and developer features.

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!