WebInspector for WebKit in VW, and some points about using WebKit as a replacement GUI.
When I first started working with rich client interfaces in the browser many years ago, both pre and post AJAX/H, the development experience was abysmal. Forget debugging - there wasn't even a log facility. Working with the browser embedded in a Java application was even worse. It was truly horrible. This was well before the advent of FireBug, which I was so overjoyed to see that I immediately sent the author some money.
Having these tools is a critical piece of my plan to use WebKit as a new GUI toolkit in VW. WebKit has them and I've integrated them into my VW-embedding. In the screenshot below you can see a WebKit based smalltalk-doc RBTab with the WebInspector active. Note that you can do live changes to the CSS in that inspector, as well as cool stuff like seeing all the resources the pages loads, how long it takes etc. That tool is itself mostly written in HTML, and is available in Windows as well as MacOSX. I imagine a Unix version wouldn't be hard.
Even though this is a full browser embedding, and you can go to any page that you can with Safari, that's not my ultimate goal - using web elements as a complete GUI toolkit in VW is what I'm trying to do.
To achieve that, I explicitly don't want to use any Javascript. The idea is not to build a webpage/webapp using the normal workflow, but to use Smalltalk wherever you would use Javascript. No JQuery/Prototype etc. This is why I'm building first-class bidirectional interop between the browser objects e.g. DOM/CSS and Smalltalk. Think of it as a native GUI for VW, unlike both the current and Pollock models, but where 'native' means DOM elements. So where you might instantiate a text field and put it into a ST canvas, in this model you create a HTMLInput element of type text, and insert it into the DOM tree. You attach event listeners in the same way you would if you were using 'normal' controls. It's absolutely no different conceptually than building a GUI using 'traditional' technology, but the view/controller portions are done using a declarative form. It's a lot like OpenGL in that respect. You can do layout calculation in Smalltalk if you wish, or you can leave it to the browser. Although given that WebKit is quite a bit more sophisticated than e.g. IE as far as CSS and layout support is concerned, that's probably not neccessary.
The quality and nature of the DOM/Smalltalk interop is key to this, and I'm intending to do more than just a DLLCC-style FFI. For a start I need to integrate the garbage collectors so that you can have DOM nodes holding references to ST event handlers that may themselves hold on to DOM nodes in a cycle. Without GC integration the programmer has to worry about the nature of references, incompatible object lifetimes, and avoiding cycles using some explicit mechanism. That's not good enough for what I want.
Avoiding Javascript also makes the problem of passivation more tractable because the serialization of the DOM tree seems to be not too difficult, including maintaining Smalltalk/DOM references to event handlers for example.
I was going to do a post about enabling rich HTML editing in the documentation view, which would be a fantastic advance. However I realized that it would be contrary to my desire to not use Javascript, so that will have to wait until I've done the DOM integration and a simple version of e.g. TinyMCE in Smalltalk. Safari does editable HTML, and I think it can be profitably used not only for rich HTML but also as a source editor that is much better than the current one. At the very least error messages should be in a gutter. I'll have to do some experimentation.
My vision for a new VW is getting closer - hence the title of my blog. I have good native code integration via LLVM/Clang. I'll soon have a new GUI toolkit that IMO will allow fantastic looking, rich interfaces that are easy to build. The next step will be to allow non-ST resources, as outlined in my post about file-based images. This will not only allow for binary assets that don't feel (IMHO) like a hack, but also makes integration of tools such as ANTLR, with a railroad diagram editor and a ST code generator, a lot more natural. And it's not a lot of work, because at each point I'm leveraging existing technology that has it's own momentum. Of course everything I've done so far is proof-of-concept. I've done no documentation yet, and I'm nervous about releasing anything before it's stable.
