In general, we've avoided cross platform UI toolkits because while
they may offer what superficially appears to be a quick path to native
looking UI on a variety of target platforms, once you go a bit deeper
it turns out to be a bit more problematic. As Amanda says, your app
ends up "speaking with a foreign accent".

Our experience is that using these frameworks also limits what you can
do to a lowest common denominator subset of what's supported by that
framework on each platform.

My initial thought was that a Windows-clone would be acceptable on
Linux provided the performance of the app itself was outstanding,
given the general reluctance of some of the team working on Linux
towards UI. But they stood up and made their case for a GTK UI, and so
if you read the other thread on this topic posted to this list
yesterday, you'll see that that's what we've decided to do. A
Windows-clone would most definitely not be acceptable on MacOS X,
where the APIs for UI development are highly evolved and have many
outstanding features. So that's always been the plan there. views is
still theoretically portable, but it's unlikely we'll ever use this
capability. The architecture of Chrome has converged over the past few
months on a solid separation of view from state, and this has given us
the flexibility to make these decisions and choose from the widest
range of alternatives.

-Ben