I’m not sure what you mean by reaching out. Native Brazil windows are native, meaning they are independent from the one Squeak window. In fact, when the image starts you don’t see the squeak window. You get whatever Brazil windows were open when you saved the image, all separate like any other windows on the system desktop. You can open the Squeak window if you need it, like I did for this screencast to demo the remapping.

Carl–

“Brazil” is after the movie, continuing the totalitarian naming trend started by Newspeak.

Torsten–

Brazil is Newspeak-only in the sense that it’s written in Newspeak, which is not backward compatible with Smalltalk. Of course, one could write a framework with a similar architecture in classic Smalltalk, or perhaps even convert the code automatically–though it wouldn’t be pretty. Also, it relies on the FFI that’s not available for Squeak yet. Two FFI layers, in fact–the low-level Alien mechanism which should find its way into Squeak one day, and a higher-level Newspeak-specific wrapper which would have to be redesigned or replaced for classic Smalltalk.

Matthias–

That’s a good question. We considered that option and no, it wouldn’t make more sense. There are several reasons why.

One, native widgets are the way to go, which rules out something like Gtk (other than on Linux where it could be proclaimed as native). With OS X for a while, and with Vista now, the visual pizzazz plank is high these days, and emulated solutions are a dead end. (And a resource black hole).

Second, while we want cross-platform support, we don’t want platform insulation. Brazil will allow a window open on one platform to migrate to another, and to write code that runs on any without changes, but it will also allow special-casing for non-portable features (say, if a button on platform A has an attribute not available on platform B). If you want a Windows-only app that relies on something only Windows can do, you should be able to build it. That’s crucial to avoid the lowest common denominator problem that all insulating frameworks suffer from. So, we don’t want another framework to create an illusion for us that it’s all the same world out there. It’s not, and we want hooks to deal with it.

Third, we don’t want a dependency on a large opaque body of foreign language code with other people’s bugs in it. The way things are now, everything beginning from the OS call back to a window procedure happens inside the image (we don’t rely on any plugins or primitives) and available for debugging, inspecting and changing in a civilized live environment. Some people may enjoy chasing pointers in gdb, but we are not among them.

Markus

[1] http://wiki.squeak.org/squeak/3862