Hi Michael,
On Sun, Apr 20, 2008 at 5:38 AM, Michael Davies mykdavies+squeak@gmail.com wrote:
What are your usage scenarios for Newspeak that are making UI development a priority at such an early stage in the development of the language?
Gilad mentioned at various points in the talk that Newspeak exists in the context of a larger application project. This was the reason why development started with Squeak and not as "come back in two years and we'll have a platform for you", and also why there was the need for a GUI early on. Plus of course, it was clear from the start that the classic Smalltalk browser model was not scalable enough for nested classes, so without a UI story it would be life with source files in Emacs.
Could you explain the relationship between Brazil and Hopscotch, and the division of responsibilities between them?
Brazil could be described as an abstract widget and layout framework. Abstract because the objects you normally work with as the framework user are some generic constructs materialized behind the scenes as artifacts of the host OS UI. (Morphic is also treated as a host UI, and the browser you saw in the demo was in fact made of morphs even though it wasn't coded in Morphic). As an example, a Brazil Button has attributes such as the label, the enabled/disabled state, and the action to invoke when it is pressed. When its container window opens in Morphic, you get a SystemWindow morph a SimpleButtonMorph inside. When the same window opens in Windows, you get a native window with a native Windows button control in it. A UI can be dynamically unmapped from one host and remapped to the other, retaining any important state. This makes a neat demo, but is also pretty much a requirement if you want to support image-based development and allow saving an image on one OS and opening it on another.
Brazil also manages widget layout, using what's essentially a capability-based model, which is interesting but best explained separately. The layout is always computed by Brazil, be it in Windows which has no layout mechanism of its own or in Morphic which does.
Hopscotch is the application framework and the browser. I myself make no distinction between the two--at least not to the point of coming up with separate names--as I've been working on the framework and the browser together from the start. But strictly speaking they are two separate things, Hopscotch-the-framework and Hopscotch-the-browser.
The purpose of the framework is to allow expressing and managing assemblies of widgets that serve a particular purpose. The purpose is usually to present and manipulate some domain objects, so the framework is essentially domain-UI glue plus some common UI tools such as the document model and navigation facilities. That's kind of it in the most general sense. There are various interesting points about the way Hopscotch does it, and I plan to eventually tell about it in detail on my blog and other venues, but it's a little too early yet. But one interesting point is that similar to how Brazil UIs can manifest themselves as widgets of different host systems, a Hopscotch application could be rendered by an underlying widget layer other than Brazil. For example, it would be possible to run Hopscotch (the browser/IDE) in a web browser by teaching Hopscotch (the framework) how to represent itself as ajaxy html. For now this is only a possibility, but the architecture has hooks to allow things like that.
Cheers,
--Vassili