This is part 3 in a 3 part post about Boxely: Here is part 1 and part 2.

Boxely is different than XUL in many ways - some are incremental improvements that could be added to XUL, and others are fundamental differences that could not easily be ported.

XML Stylesheets - One of the most visible differences between Boxely and XUL is that Boxely's cascading stylesheet language is not CSS. Boxely stylesheets are just XML. Unlike CSS, these stylesheets can contain more than just style rules; they contain objects such as bitmaps, brushes, gradients, and animations which can be re-used and shared. In this way, the stylesheets are like a mix of CSS with SVG and SMIL.

Data Binding - Boxely had a very simple data binding system, although I can't tell if it still exists in the current beta. Unlike XUL, which requires that you beat your data model into a bloody RDF graph, Boxely simply asked you to implement a simple interface that mimicked a hierarchy. Better yet you could just bind a hierarchy of Python objects without having to write any new code.

Animation - Boxely supports an animation system similar to SMIL. Unlike SMIL, it is integrated with the style system, so you can write something like "when the mouse is over this text, play the animation that makes it glow from its current color to blue". You'll notice this kind of animation is very common in AIM, because it is so easy to write.

Absolute Positioning - Any Boxely element can be taken out of the flow and positioned absolutely, or relative to some other element. This works something like HTML absolute positioning, but goes a lot further. You can attach an element to any other element in the DOM, and make its position and size relative to that other element. For example, you could add a "sticky note" anywhere in the DOM, and then tell the sticky note to attach to the bottom-right corner of some button, and it would stay there even as the window is resized.

Z Ordering - Every Boxely element recognizes the "z-index" style. In XUL, there is only one Z order, and it cannot be changed. You'd be surprised how annoying this is. It's very common to want to draw something above or below another element, regardless of where the two are in the flow.

9-slice Backgrounds - Boxely supports 9-slice image backgrounds, which allow you to use a single image as the background for something like a button, in which the edges do not scale but the center does. This is really the only way to go for skinning resizable widgets that contain text.

Flow Layout - Boxely supported a layout model in which elements would wrap around to the next line when they overflow their container.

Tray Icons - Boxely lets you easily put an icon in the system tray with a control called "statusIcon". You can even attach a context menu to the tray icon the same way you'd attach a menu to any other control.

Popping out of Windows - Any Boxely element can drawn outside of the bounds of its window. This makes for some really neat tricks. I used to have two demos to show this off. One was a window with a drawer, like in OS X. The drawer was actually positioned at negative coordinates. The other drawer was a mock of the OS X dock. When icons balloon out as you mouse over them, they become wider than the dock itself, which is bounded by the main window, but the overflowed portions of the icons are still visible. Behind the scenes the native window is just expanded and repositioned seamlessly.

No-Nonsense Drag and Drop - Boxely doesn't require you to write a ton of script to do drag and drop, as XUL does. Setting and getting the data to be dragged is one line of code, where in XUL it takes dozens. As a bonus, it is trivial to create an image to follow the cursor during a drag with Boxely - you simply point to any box in the DOM, and the box is rendered to an offscreen buffer and fed to the OS drag and drop API.

Two-Way Broadcasters - Boxely supports two-way broadcasting of attributes. Mozilla supports only one way. Two way binding means, if an element is observing the broadcasted attribute "foo", and I change the value of "foo" on the element, it updates the broadcaster to its own value. This allows you to keep a bunch of stuff synchronized without any scripting.

Re-usable Event Bindings - One of the goals of Boxely was to make it easy to write new controls that "feel right". One of the ways that home-grown controls often don't "feel right" is if they don't support the keyboard and mouse interaction that you expect. For instance, if you write a new listbox-like control, I expect that typing shift-home is going to select everything from the current row to the top, but too often this sort of thing doesn't work. To make this trivial, Boxely supports something called "behaviors", which allow you define a set of event bindings that can be re-used. If you implement one of the common behavior interfaces, such as "selectable" or "button", you'll automatically get the correct keyboard and mouse bindings for the operating system. In XUL, every control author has to re-invent their behaviors from scratch, and they usually miss a few things.

Out-of-line Scripts - Boxely supports something like Mozilla's XBL, called Gadgets. The most important difference here is that Gadget methods and properties are not embedded in XML, as XBL's are. I always hated this about XBL, because an XML description of a class is so ugly and long-winded compared to the straight Javascript equivalent, plus you lose the Javascript syntax highlighting in your editor. So, Boxely Gadgets import a JS file and binds all of its global variables and functions as interface to the class.

Executable Files - Boxely applications could be started just by double-clicking any Boxely XML file. There was no need to package the app in a zip file and write a "manifest", though you could if you really wanted to.

NO COM - If you wanted to make your components scriptable, you wrote a Python binding, which is easily automated using a number of tools like SWIG. Then you got all the glories of the Python object system, and no nasty IIDs and ContractIDs polluting your code. Of course, AOL has decided they like COM, and so this feature is no more.

There are lots more features I could go on about, but you get the idea. The only regret I have is that I didn't make it open source from the start. Now AOL owns it, and I am left watching my creation grow out of my control.

On a closing note, I have a suggestion for my friends at AOL. If you were to port Boxely to OS X and Linux, and maybe, oh I don't know, open source the library, I think you'd have a real winner on your hands! ;)

This is part 2 in a 3 part post about Boxely: Here is part 1.

Boxely was developed during the year in which Netscape engineers had nothing to work on, because AOL couldn't decide whether or not they wanted to keep us employed. AOL did not ask for Boxely, nor did they know that I was working on it. Sometime in July 2003, some people at AOL discovered my project. It turns out that they had been looking for a lightweight GUI toolkit for some time to replace their decaying, decade old system. In a strange twist, a few days later AOL layed off everybody at Netscape, including me. When the folks who found Boxely heard that I had gotten the axe, they pulled a few strings and I was given my job back. Not only that, but they created a whole new team dedicated to Boxely and asked me to lead it. I was thrilled initially, but over time I couldn't shake the feeling that AOL wasn't the right place for me, so I left the company in February 2004.

Fortunately, AOL kept Boxely going and has improved it quite a bit since then. It seems that it is now central to their plans for the future. I can only speculate what these plans are, but one thing seems certain: AOL wants you to use Boxely (and the rest of the AOL platform) to write your own desktop applications.

Before I talk more about what Boxely is, I should mention what it used to be. Boxely was tiny. Now, Boxely has become dependent on this "AOL Services" thing, which seems to be yet another portly COM-based platform. As a result, AIM consumes around 50MB of RAM and uses 4 separate processes. Ouch. I'm sure they're working hard to shrink the footprint. Still, as one of my motivations for Boxely was to escape Mozilla's giant COM layer, I'm not too thrilled about this. Oh well, I quit and left the project, so I can't complain.

Boxely was also supposed to be cross-platform. Although I only implemented the Windows side, the code was designed to make it easy to support other platforms. I don't know if AOL has plans to do this in the future, but as far as I can tell the AIM beta is all Windows to the core.

Boxely originally used Python as its scripting language (hat tip: Rob Ginda). AOL didn't seem to appreciate Python's infinite superiority, as they immediately ripped it out and replaced it with Javascript. I guess they'd rather appeal to the web developer crowd than support a language that doesn't suck.

The biggest improvement AOL has made to Boxely is its rendering engine. Boxely originally used GDI+ for all graphics. AOL replaced GDI+ with a ridiculously fast graphics library it bought a few years ago. This new library's performance blows GDI+ away, and should support some pretty zippy vector graphics and animation.

So, AIM is now just like Firefox in that anybody can look at the source code behind its UI. If you dig around in in "C:\Program Files\Common Files\AOL\AIMBeta\services", you will find a bunch of XML (.box) and Javascript files. Specifically, look in "imApp\ver0_1_12\content" to see the main AIM UI files. If you wanted to do something naughty, like maybe remove the banner ad from the top of the buddy list, you could do that simply be making a simple change to an XML file. If you wanted to do something nice, like add a whole new feature to AIM, you could do that too with relative ease.

In the final part of this series, I'll look more closely at Boxely and show how it differs from XUL.

Today AOL released a beta of the next version of AIM. This is probably not a big deal to most, but it is a big deal to me, because this AIM has now been re-written from scratch using Boxely, a GUI toolkit that I designed and implemented during my final year at AOL.

Boxely is an XML and Javascript based system for building desktop GUI applications, in the same family as Mozilla's XUL and Microsoft's upcoming Avalon. Just as XUL makes it really simple for people to write browser extensions for Firefox, Boxely makes it easy to write extensions for AIM. I don't know if Skype should be worried yet, but it seems AOL is interested in making AIM an attractive platform for all kinds of communication.

Boxely began its life in late 2002 when I came to the sad conclusion that "Mozilla, The Platform" was not what I wanted it to be. At the time, my friend Marlon and I had been working furiously for months to develop "Dante", an idea we had for a new desktop application. Naturally, I elected to build the first version as a Mozilla application using XUL. While I had loved XUL during the years that I used it to build Netscape/Mozilla products, I grew frustrated with it as I built Dante from the ground up, for a number of reasons:

As a seasoned Mozilla developer, I certainly had the ability to improve XUL, but I decided, in the great tradition of Netscape, to start over from scratch. Even if I had been able to fix some of my complaints about XUL, Mozilla would still be large and "COMtaminated". More importantly, since Mozilla intends to keep its XUL implementation backwards-compatible with Mozilla 1.0, I'd be pretty limited in how far I could change things.

So, I spent a few months building a new lightweight, stand-alone XUL, named for the "box" objects at its core. It started out very similar to XUL, but evolved to be different in a lot of ways. Once Boxely was mature enough, I used it to re-write Dante. The Mozilla-based Dante had been a 10MB download that took about 25MB of RAM on startup. The Boxely-based Dante was a 1MB download that took about 8MB of RAM on startup, and was faster, nicer looking, and easier to develop.

Over two years later, "Mozilla, The Platform" has improved quite a bit. If they can get rid of RDF templates, make the layout model more versatile, support more graphical features, and finish XUL Runner, I'd call it a contender. I have heard Mozilla talk about making "The Platform" more of a priority for the post-Firefox 1.0 world, so I'll keep my fingers crossed. The open source world really does need a cross-platform answer to Microsoft's XAML. It's not clear if AOL intends to make Boxely either cross-platform or open source.

So, what is Boxely, anyway, and what does it mean to you, the GUI developer? In my next post I will look at how Boxely has changed since I left AOL, and in the final post I will show how Boxely compares to XUL.