The creation of a new order of things

My intention for this integration goes well beyond the obvious benefits of having a browser widget available in VW. The inspiration for this is the work that ActiveState have done - have a look at this screencast. After seeing this many years ago I developed a JavaWebStart-deployed CMS client using both Gecko and IE integrations on Win32 and OSX. That client (and the associated CMS server) has been paying our bills for many years now. Ironically I'm now rewriting it to use AJAX in a pure-browser environment, but that's because a) AJAX has come a long way since I first shipped that product; b) my primary client uses Citrix and wants to go a lot wider into the organisation; and c) I've moved a lot of our software to VisualWorks.

There is a dominant UI toolkit - it dominates by a massive degree, and it's not Win32. Rather, it's the web browser and DHTML/CSS. Obviously desktop UIs have some facilities that the browser doesn't, but in both OSX and Win32, the browser is used to implement some UI features, and could do a lot more. I think there are two interdependent forces at work here. Firstly, users accept the use of HTML, especially the AJAX/Web 2.0 form, as a valid form of UI. Secondly, the facilities in the browser for doing functional, usable and attractive UIs are continuously improving.

My goal is to integrate Smalltalk with the (extended) DOM in a seamless bidirectional fashion that makes ST objects first class entities in the browser environment, and similarly reifies the browser environment into Smalltalk so that e.g. DOM nodes are first class objects. This will allow you to do things like set blocks as DOM event handlers, without going through some AJAX or Javascript bridge, and to use a 'browser view' to implement anything from a single button in a VW UI to an entire window. I would also like to allow the reverse embedding where a VW UI element (of any scale) can be used as a HTML view element.

I originally intended to do this using Gecko, and I've built and published an XPT library for that purpose. However I stated looking at Webkit recently after seeing some posts about the quality of the source, and the fact that KHTML is being replaced/re-merged with Webkit, which means that Webkit will be available on OSX, Win32 and X11. Obviously WebKit lacks XUL, which is very useful for building richer UIs, but I'm not yet sure if that's enough to offset the fact that the code is a lot easier to work with.

I think the key difficulties will be threading, and integration of the GC environments to allow cross-domain tracing.

So, my goal is similar to Pollock's - to provide a complete UI toolkit. There are some key differences however, which IMO avoid the pragmatic issues that cause the abandonment of Pollock:

1. This is an integration effort only. The UI, with all of it's devil-in-the-details complexity, is already done.
2. There is an significant development effort behind improving the browser, from MathML to SVG, Canvas etc.
3. HTML/CSS et al is well known and extensively documented.
4. By allowing the browser to be embedded in an existing VW UI, and allowing a VW UI to embedded in the browser, you won't have to choose one or the other.
5. Depending on how you use it, using the browser as the UI toolkit can be either partially or completely equivalent to providing a web UI for an application

Obviously one of the Pollock issues remains, namely the significant effort of transitioning the tools. However, porting the RB with only a few of the content tabs, plus workspaces, would be 99% of what I use in VW, and while I'm not sure about the amount of effort, my gut feel is that it's doable given the RB was originally cross-platform. And in any case it's an interesting project.

And of course, another potential benefit is what this kind of facility would allow you to do with Seaside tools, but that's another discussion entirely :)