Ruby has the SymbolValue 'controversy', just like Smalltalk.

I saw Heroku mentioned this morning on TechCrunch. It integrates everything from generation to deployment to the cloud, with code management. Editing looks OK.

Ruby and Rails are juggernauts, and there's a lot of attention, training, documentation, and VC money going into it. I hope Cincom are putting enough resource into WebVelocity, because on all of the non-technical issues (which is what actually matters), the 80/20 solution is a giant.

I spotted this in the WebKit mailing list: Clutter. From the home page ...

Clutter is an open source software library for creating fast, visually rich and animated graphical user interfaces.

Clutter uses OpenGL (and optionally OpenGL ES for use on Mobile and embedded platforms) for rendering but with an API which hides the underlying GL complexity from the developer. The Clutter API is intended to be easy to use, efficient and flexible.

Clutter currently features the following:

• Scene-graph of layered 2D interface elements manipulated in 3D space via position, grouping, transparency, scaling, clipping and rotation.
• Frame based animation engine providing path interpolation, transitions and other custom effects via Behaviours and Timelines.
• Scriptable JSON based layout and animation file support.
• Advanced input event handling.
• Custom Pango renderer providing efficient internationalised UTF8 text rendering.
• Support for high end Open GL features such as Shaders and FBOs.
• Support for media playback with GStreamer, Cairo graphics rendering and GTK+ embedding are available via optional add-on libraries.
• Object oriented design via GObject with a familiar GTK+ like API.
• Runs on Linux, Windows and OSX with backend window system support for GLX, EGL, SDL and Cocoa.
• Support for mobile devices with fixed point internals and portability across Open GL and OpenGL ES
• Developed in C, with language bindings for Perl, Python, C#, C++, Vala and Ruby.

Clutter aims to be non specific -- it implements no particular style, but rather provides a rich generic foundation that facilitates rapid and easy creation of higher level tool kits tailored to specific needs.

Clutter is free software released under the GNU LGPL. It is supported by both a growing open source community and commercially by OpenedHand.

Visit the clutter blog for the latest Clutter news, developments, screen shots, screen casts and more.

There is an in-progress port of WebKit that uses Clutter as it's backend.

This might be a richer outcome for VW than a pure Cairo binding.

My work on the VW version of GroupLayout has reached a usable state (although it's not finished). The window in the following screenshot is layed out using this new system.

All of the spacing is symbolic, and deferred to the UILookPolicy. Components can be baseline/top/left/bottom/right aligned, and not just in a hierarchic table-like fashion. I've implemented most of the system described here, although currently the baseline/preferredSize/minimumSize/maximumSize methods don't cover all of the UI components (and really only in ASBAqua). That's just because I haven't got around to it yet, not because it's difficult.

The linkSize mechanism isn't implemented because I haven't yet figured out how to do it, and replace and honoursVisibility may not be relevant. I intend to implement a Cocoa-like visualInsets mechanism that preserves alignment in the face of shadows/focus indicators - visual alignment is often not the same as bounding box alignment. Finally, I'm going to look into allowing the min/preferred/max dimensions to control the window sizing, so that you don't have to specify those properties on the window.

The important thing about this layout mechanism is that it can adjust to different fonts, different widgets, and different platform policy regarding spacing, all while preserving alignments and relationships. It responds well to resizing, and interoperates with the existing layout mechanism. It will give good results across platforms and L&Fs Furthermore it contains no explicit positioning, apart from specifying some preferred dimensions for e.g. popup menus and lists, that have no natural size independent of their model.

The layout code is reasonably verbose, but not as verbose as explicitly dimensioning every component. The layout code can be partitioned if there are sections of the UI that have strict rectangular bounds without external alignment requirements e.g. the filter specification at the top of the example dialog. Furthermore it's amenable to more convenient construction mechanisms such as regular grids, whilst maintaining identical behaviour to a non-hierarchic canonical specification.

This is all published in the Public Store (undocumented as yet), as ASBRB, although note that it requires StoreGlorp (because that's where the dialog is from) and you must be using ASBAqua, and hence the OSX L&F, on OSX. It will pull in a number of other packages that I've published as bundles such as Linkuistics and LinkuisticsUI. You can test two different versions of that dialog in a workspace:

ASBReplicationUIGroupLayout open

ASBReplicationUIMixedLayout open

The MixedLayout version uses the traditional layout mechanism for some of the controls, and a simple TableLayout for a few items. That's 'Mixed' as in 'Mongrel' :)

GroupLayout was originally designed for use with the Matisse UI Builder, and so it has a natural representation and interface when used in a visual context. I've haven't done any UIPainter integration, and at this stage I don't intend to, purely because I have no commercial imperative to do so and I have some other projects that are more important to me. Having said that though ...

I know that this layout mechanism can be incoprorated into UIPainter, which could also be significantly improved in other areas. The VW UI has often been mentioned in the mailing list as a significant stain on the product. Presuming that I first did all of the cross-L&F work to complete GroupLayout e.g. baselines etc, I'm wondering if there are any Cincom clients who would be interested in funding the work required (I estimate 3 months), on a shared-cost basis, to update the UIPainter to incorporate this style of layout and make it best-of-breed, rather than, well, whatever it is now. Yes folks, that's an ad.

As a precaution, I need to say that regardless of the URL of my blog, I am in no way affiliated with Cincom.

This post is primarily about some ongoing work I'm doing to improve the VW UI framework, focussing in particular on improving the layout machinery and platform fidelity.

As part of my Aqua L&F improvements I implemented an improved resizing splitter control. The way splitters work in VW is quite ugly - and that ugliness comes from VWs layout machinery and specification. The problem I had to work around is that VW layout forces the user to encode the size of controls in the layout. Layout is one of two major blights in the UI framework, the other being font and text handling.

There are other issues with the VW interface code, such as a very limited drawing facilities, but unlike the layout mechanism I don't classify that as a problem of poor design - it's just old.

A layout problem example

Consider a window containing a single vertical split. Currently you have to place three components with the following layout, where the numbers shown are the x-axis left/right ratio/offsets

 [ Left ]      [ Splitter ]      [ Right ]

 0   0.5-2  0.5-2      0.5+3  0.5+3      1

Note how the width of the splitter is encoded in the layout. It so happens out that the Aqua splitter is 9 pixels in the minor axis, but VW UIs are all encoded with a smaller size. Regardless of the actual value, the important fact is that it's an L&F parameter, and shouldn't be part of the user-specified layout.

I hacked a fix for this in ASBAqua by doing a one-shot initial adjustment of the dependent view's offsets which allows the splitter to determine it's own dimensions. But it is a hack and it immediately made me wish that splitters worked by containment i.e. the splitter component should contain the views it splits, and manage their layout.

After doing some work to improve the Aqua L&F I was intending to get back to working on version control, but this looked like some low hanging fruit of general applicability, it was an excuse to learn something about the UI internals, and it could resolve some issue I hadn't been able to solve in ASBAqua.

I also wanted to do some experiments with the navigation UI of the Refactoring Browser, although this was before saw the reaction to James Robertson's thought-experiment post about the RB UI. It seems to me that many Smalltalkers believe that everyone would see the obvious advantage of Smalltalk, if not for their lack of imagination, and adherence to what they already know. Yet reading the responses to that post - what irony! Maybe things were different in the days when Smalltalk didn't have the weight of a tradition; maybe it's the rebellious teenager become conservative adult, their once original ideas crystalized as dogma. Eclipse is not a piece of crap. Neither is Java, nor Haskell (the epitome of static typing), nor Scheme, nor anything that isn't Smalltalk.

Anyway, it's been quite a detour but I've ended up overhauling all of the layout mechanism in a backwards compatible fashion, and providing a number of smaller, but very useful enhancements such as Controller/View merging, and a Seaside canvas model for manually generating UIs - although I've come to the conclusion that visual UI building is in fact preferable, as long as the tool is really good. It's all done a way that either is already, or can be made compatible with, an improved UIBuilder, which I also discuss.

Containment based splitter

The first thing I did was to subclass CompositePart to make a splitter container. Turned out to be trivial, which was a pleasant surprise.

In order to test this I subclassed the refactoring browser and overrode the window spec. I converted the spec literal array to code that creates the Spec objects. This doesn't stop the UIBuilder working, and adding a single override in UIPainter allows such specs to be opened in the painter. It would be an easy mod to have the specs serialized out of the painter as code rather than literal arrays, which IMO would be preferable because it would make the construction of the UI less opaque.

At this point it was still passive i.e. it didn't respond to the mouse. Here's the window spec:

windowSpec

  <resource: #canvas>

  ^UI.FullSpec new

    window:

        (Linkuistics.UI.LUIWindowSpec new

            bounds: (0 @ 0 corner: 800 @ 600);

            min: 472 @ 312;

            menu: #menuBar;

            toolBar: #toolbarMenuHolder;

            useSavedDimensions);

    component:

        (Linkuistics.UI.LUISplitterSpec new

            initialFraction: 0.33;

            beHorizontal;

            add:

                (UI.SubCanvasSpec new

                    majorKey: #NavigatorTool;

                    minorKey: #windowSpec;

                    clientKey: #navigator;

                    name: #navigator);

            add:

                (UI.SubCanvasSpec new

                    majorKey: #CodeModelSubcanvas;

                    minorKey: #windowSpec;

                    clientKey: #codeTool))

Note the lack of layout. The splitter does the layout for it's children, so they don't need any, and the default layout of my composite class is a LayoutFrame with (0.0+0,1.0+0) in both axis.

I subclassed the WindowSpec so that setting the menu also sets the flags that indicate a menu should be used. That could be a WindowSpec override, but I bet it would break someone, somewhere. Damn you, whitebox! :)

The UIPainter correctly shows the containment in this spec, but it really doesn't handle containment in any meaningful way. It's not that it couldn't be done, and probably without too much effort, but it currently presumes all views are peers except for one specific type of group.

A merged Controller/View generic container

To get the event handling working in the composite splitter, I copied code from Searchlight. Michael Lucas-Smith had developed a merged Controller/View using a state machine concept with state-based selectors e.g. if you are in 'pressed' state then the selector is "pressedMouseMovedEvent: anEvent", with a fallback to "MouseMovedEvent: anEvent", along with optional handlers for state transitions. It worked easily for my case and was very simple, but by this stage I was thinking about my composite in more ambitious terms. I couldn't see how to generalize and scale the FSM mechanism, particularly when dealing with components with many possibly coincident mouse regions, with a separate set of states for mouse-down tracking, each of which might involve different logic depending on where the mouse was originally pressed or what the keystate was (or is, during tracking).

This problem gave me a week of sleepless nights - literally. In the end I decided the solution required a model with less architectural commitment, so I developed a hybrid architecture. Each view has a (standard) tracker object that both handles mouse events and stores state relating to the tracking. The object is created every time the mouse enters the view and released when it exits (grabs don't exit until the mouse is released). In effect it acts as a transient controller, but it contains no user code and forwards filtered events to the view, using a "mouseMoved:/mousePressed:/mouseDragged:/mouseReleased:" protocol, with separate methods for different buttons ("rightMousePressed:/centerMousePressed:" et al). It handles drag offset increments, both from mouse press and last drag event, with limits that allow you to filter out drag events that would drag an object out of bounds whilst maintaining correct offset increments. It handles cursor tracking by sending cursorForPoint: to the view. I originally had a Cocoa NSView-like mechanism for declarative cursor regions but it was overkill for my particular use case, and in any case NSView uses it because it prefers not to deliver mouse motion events to the view. You can override the class of the tracker to extend it with additional mouse-only transient state and behaviour, although adding non-policy-pattern behaviour would conceptually de-merge the Controller from the View. The reason it's transient is so I could be profligate with state without burdening the view. I anticipate adding functionality to the generic tracker for e.g. processing points for path construction, selection rollover, and handling transient key states to modify mouse behaviour e.g. shift/ctrl-down. Adding these things to the tracker simplifies the view whilst still allowing the Controller/View to be merged.

I don't know if this general architectural device is that useful for key handling - although focus provides a similar lifecycle boundary, there is less dynamic state involved. Even so, it might be worth it just for the sake of architectural uniformity.

After fixing a few bugs in the EventDispatcher that deal with exit/enter events, the splitter was fully functional.

A Seaside canvas model of spec construction.

I suspected I was going to be doing a lot more nesting as this work progressed, so I wrote a simple Seaside-like canvas model for building specs. The canvas model is very convenient for nested structures, primarily because of the "with: [...]" pattern. Using a block without an argument makes out-of-order construction less convenient, if not impossible, because the stack is transient and the top of the stack implicit, but that's an appropriate trade-off for Seaside because it allows the canvas to be streamed. That's not a requirement in this case because the result is a data structure, but I stuck with the niladic block because it looks better. The implementation is trivial, primarily because I use proxies around the specs rather than specific brush types. This is a necessary feature for non-intrusive arms-length interoperability with user-defined specs.

Here's what the refactoring browser window spec looks like now:

windowSpec

  | canvas |

  canvas := Linkuistics.UI.LUICanvas new.

  self windowSpecOnCanvas: canvas.

  ^canvas fullSpec.

windowSpecOnCanvas: canvas

  canvas window

    bounds: (0 @ 0 corner: 800 @ 600);

    min: 472 @ 312;

    menu: #menuBar;

    toolBar: #toolbarMenuHolder;

    useSavedDimensions.

  canvas splitter initialFraction: 0.33; beHorizontal;

    with:

        [canvas subCanvas

          majorKey: #NavigatorTool;

          minorKey: #windowSpec;

          clientKey: #navigator;

          name: #navigator.

        canvas subCanvas

          majorKey: #CodeModelSubcanvas;

          minorKey: #windowSpec;

          clientKey: #codeTool]

The improvement is more obvious when dealing with more complicated UIs.

A number of ideas occur looking at this. The canvas could do the building, rather than creating a separate spec tree. The UIPainter could capture the structure by using a different canvas class. By using a pattern such as "canvas render: self using: #selector with: ..." to partition the code, the UIPainter could also preserve the decomposition of the UI into separate methods when it regenerates.

Enriching the dimensional model of parts

The next step was to attack a more complicate example - the GlorpStoreReplication (GSR) window. Apart from the now-fixed splitter issues, the two issues I wanted to fix were a) the checkbox label baselines don't line up with the input field text baselines; and b) The ">>" button changes size as the window changes size, and I couldn't see a way to fix the dynamic behaviour of the button using the existing layout mechanism. Of course everything was explicitly positioned using layout objects. I could fix the alignment issue explicitly for a particular L&F, but not in a generic fashion e.g. one L&F would be right and the others not.

This is what the GPR window looks like without any modifications:

The first problem I looked at was the issue of vertically aligning views on a baseline. Font metrics calculations in VW are very basic - just a line height and descent. Furthermore, the values the VM returns on OSX are wrong because it does some rounding in the primitive. I did some work to allow you to manually specify top/bottom leading, ascent and descent for a font which gives me a correct baseline for the 11pt Lucida Grande used in ASBAqua, but I subsequently realised (obviously) that for baseline alignment in single-font UIs it doesn't matter if it's wrong, because it's only used in a relative fashion. A good reason to want correct values however is so that you can line up text within controls, which you can't really do unless you know the ascent and descent and top leading. Top leading wouldn't be necessary if text was drawn relative to the ascent, but as should now be obvious, VW draws text relative to top leading + ascent, whereas the visual weight of the character lies between ascent + descent. The VM draws text according to it's naive and incorrect baseline, which therefore needs to be preserved, so I added parallel values for the four corrected parameters that can now be set as shown below (the example is from ASBAqua). Font metrics for character advance/widths are also wrong, at least on OSX, but fixing that is not in scope for this diversion.

defaultSystemFontAttributes

  | characterAttributes textAttributes |

  characterAttributes := CharacterAttributes newWithDefaultAttributes.

  characterAttributes setDefaultQuery: 

    (FontDescription new name: 'Lucida*Grande*'; pixelSize: 11).

  textAttributes := Linkuistics.UI.LUITextAttributes new.

  textAttributes setCharacterAttributes: characterAttributes.

  textAttributes lineGrid: 16.

  textAttributes baseline: 10.

  textAttributes luiTopLeading: 3.

  textAttributes luiAscent: 9.

  textAttributes luiDescent: 2.

  "luiBottomLeading = lineGrid - luiTopLeading - luiAscent - luiDescent"

  ^textAttributes

Once this was done, I simply added baseline methods to the relevant wrappers and parts. For top/bottom/left/right alignment purposes however, you also need another set of dimensions, which are the visual body alignment points. Typically these are inset somewhat from the part bounds because they represent the visually significant lines in the control, such as the top and bottom dark grey lines in OSX buttons. The part bounds extend beyond that because of shadows and focus indication, so you can't use the bounds for alignment purposes. Each type of control, and each visual variant within a control (OSX has many), can have a different amount of inset from the bounds, so it does have to be on each part. I haven't done this yet because I'm focusing on baseline alignment to start with. When I do, I'll add a visualInsets method to Wrappers and Parts, because the insets are typically constants wrt. a given L&F.

A table based layout container

At the top of the GPR window is a matrix of text fields and checkboxes. The obvious solution is a table layout, ala HTML. This was very easy, involving spec classes for tables, rows and cells, and a table part. The rows and cells are part of the table data structure rather than being represented as parts, but there's no isomorphism requirement on the spec and part trees, so that posed no problem. Although maybe I'm misunderstanding the role of SpecWrapper?. I implemented a non-configurable layout to start with - vertical baseline alignment with allocation being equal to the component preferred bounds in both axes. This immediately threw up a problem with input fields: the preferred bounds of an input field is the size of it's content. I solved this by adding a width attribute to the input field, which is a sort of poor-mans layout spec. My intention was that the width attribute could be a string containing some exemplar text that would be measured to generate a preferred width, which would allow the font metrics of the part to determine the actual width with the user supplying the exemplar at design time. However I've only implemented a numeric width so far.

When I got around to including popup menus in the table, a similar problem occurred, although in this case a popup menu doesn't really have a preferred bounds. It could consult it's model to determine the maximum width, but the model is dynamic, so either the menu would potentially change width as the model changes, or it would only reflect the initial model contents. And in any case, sometimes the model will be empty. An exemplar string width mechanism would have worked, but as a shortcut I decided to use the component's existing layout specification (if supplied) to determine the width while ignoring the layout's height calculation.

Allowing LayoutFrames to be only partially specified would be a good idea that would have obviated the need for a numeric width or special handling of the layout height. The width of a component could be fixed whilst allowing it to keep it's preferred height. The fact that you can't do this requires a nasty hack in ASBAqua to reset the height of input fields, which should be sized according to the font metrics but end up being a user-specified (incorrect) height because FrameLayout determines the height and width. I couldn't just modify FrameLayout because the change would likely break existing code, and I wanted to transparently 'fix' existing UIs.

The canvas mechanism really comes into it's own with this layout. Below is the method that specifies the spec of the filter properties. Note that there are no calls to add cells within rows. Because single component cells are quite common, the table puts each component added to a row outside of an open cell into a new cell.

filterSpecOnCanvas: canvas

  (canvas table)

    layout: 4 @ 2;

    cellSpacing: 5 @ 2;

    with:

        [canvas tableRow

            with:

              [canvas checkBox

                model: #topLevelOnly;

                helpText: 'Should we retrieve only top level items, meaning things not contained by a bundle.';

                label: 'Top Level Only'.

              canvas checkBox

                model: #queryPundleName;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Named'.

              canvas inputField

                model: #queryPundleNameText;

                width: 150;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText: 'Find pundles whose name matches this.'.

              canvas checkBox

                model: #queryPublishDate;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Published in the last (days)'.

              canvas inputField

                width: 150;

                model: #queryPublishDateText;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText: 'Has this been published in the last N days.';

                type: #number;

                formatString: '0'].

          canvas tableRow

            with:

              [canvas checkBox

                model: #retrieveBundles;

                helpText: 'Should we retrieve bundles?';

                label: 'Bundles'.

              canvas checkBox

                model: #queryClassName;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Defines Class'.

              canvas inputField

                width: 150;

                model: #queryClassNameText;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText:

                    'Find pundles that define this class.' ,

                    ' Unlike method/shared queries, this is a short classname.'.

              canvas checkBox

                model: #queryPublisher;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Published By'.

              canvas inputField

                width: 150;

                model: #queryPublisherText;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText: 'Things that have a version published by someone matching this name.'].

          canvas tableRow

            with:

              [canvas checkBox

                model: #retrievePackages;

                helpText: 'Should we retrieve packages?';

                label: 'Packages'.

              canvas checkBox

                model: #queryMethodsInClass;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Defines Methods In'.

              canvas inputField

                width: 150;

                model: #queryMethodsInClassText;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText:

                    'Find pundles that define methods in the given class.' ,

                    ' For class methods, use "%Name class".' ,

                    ' This is the long class name, so "%.ClassName" is a good idea.'.

              canvas checkBox

                model: #queryMethodName;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                label: 'Defines Method'.

              canvas inputField

                width: 150;

                model: #queryMethodNameText;

                callbacksSpec: (UI.UIEventCallbackSubSpec new valueChangeSelector: #updateSourceItems);

                helpText: 'Find pundles that define a method (class or instance) matching this name.']]

And this is what the window looks like with all the modifications described so far:

Obviously there's more to do. For example: the window contents should have a platform-specific border indent, the spacing between controls should match platform specs, and the table of filter elements doesn't resize. If it did resize, then the text input fields should take up the extra space while ensuring that both columns remain the same width. Currently when the dialog expands the button between the two major sections expands as well. I can't currently think of any existing layout spec that would preserve the size of the button and the space on either side while still distributing the extra space between the left and right components. Here's an Interface Builder version of that dialog (with a layout error :).

I've haven't given much thought to how the functionality of this dialog could be improved - I'm only trying to fix the existing layout - but if this were an OSX application I'd use a predicate editor control.

Different models of layout

The next step was to add more parameters to the table layout, both for different alignments and to control column widths, both static and dynamic. But I've always found the limited specifications available with HTML tables to be annoying, so I wanted to do something better. My first thought was to make vertical and horizontal guides into first class layout entities, with controls aligned to guides rather then to each other. The attraction of this idea is that it has an obvious visual representation in the UIPainter, and to my mind at least would be easy to understand. Of course the guides themselves need to move to maintain spacing between components. I suspected that the constraints could be be solved using linear allocation on each axis independently, with some mechanism for nesting and allowing correlated dimensions for non-adjacent components.

This looked like a good point to do a literature search on using constraint solvers for UI layout. Coincidentally, a lot of work in this field was done by Alan Borning in Smalltalk, funded partially by OTI. I looked at a lot of papers, and the one that was most appealing (and most recent) was User Interface Layout with Ordinal and Linear Constraints, which is followed up in this paper. Conceptually it's similar to what I had imagined, although they've done the heavy lifting.

Another category of result that came up in searches was Java layout mechanisms, particularly FormLayout from Karsten Lentzsch's JGoodies product (which I've used extensively) and GroupLayout, which is used by the Matisse UI Builder. I have no experience with GroupLayout because it was introduced after I had stopped doing Java UI work. I'd forgotten about FormLayout, but once reminded I realised that it was a much better option than replicating the HTML table model. FormLayout is supported by a number of Java UI builders, such as jFormDesigner, and Instatiations WindowBuilder Pro.

In hindsight it's obvious that Java is the place to look for ideas about this stuff. Swing has exactly the same issues as VW because it's uses synthetic components, and UIs have to adapt to different L&Fs and different font metrics. I'm still amazed at how I didn't realise this given I've been working in Java since the mid 90s, and still do. Talk about not seeing your own nose!

For now I've decided to concentrate on the GroupLayout layout manager, on the basis of it's relative simplicity and the fact that I'm impressed with Matisse. It also seems conceptually related to both my idea about first class guides and the Lutteroth and Weber papers.

Programmatic vs. Visual UI design

The quality of the UI builder experience that can be supported by different layout systems is a critical factor in the choice of a layout system, hence the relevance of the UI Builder support for the Java layouts I mentioned above. In a couple of blog entries recently, I said that I wasn't a fan of Graphical UI Building. I've reflected on that since, and realise that most of my antipathy comes from doing an enormous amount of Web work where I had to take HTML generated by Dreamweaver and similar tools, clean up the structure, and convert to CSS for use in dynamic page generation. When it comes to HTML, I far prefer the Seaside technique.

However, I have never programatically generated a GUI on NextStep or OSX. It wouldn't occur to me not to use Interface Builder. So I think the issue is more the quality of the tool, and how well it's integrated into the language/OS/environment. Thus my opinion about UI building in VW has completely changed. I think the appropriate course is to improve the UIPainter - which IMO is ugly both in it's own right and because of the existing layout system. Obviously all of these changes need to be compatible with the existing infrastructure, which I think is possible, especially considering that I've been using a mix of new and old layout mechanisms as I've been developing. Improving the UIPainter doesn't seem like too much work, especially if it could be forked.

And I've got an inkling that these layout techniques can be used to layout HTML as well, which opens up some interesting options for visual design of interfaces that are serialised as Seaside canvas code. IMO any system that doesn't allow people to use a visual designer is going to have a limited market. Having said that though, a small slice of an enormous pie can still be a lot of pie :)

The end ...

OK, that's quite a dump :) The reason I've posted this is because I'd really like some feedback, and I have to put it down for a bit to do some Java webwork for a client. Given this is my first trek into the guts of the UI I may be missing some critical problem. Am I out to lunch? Does anyone have an pointers to other useful work?

All of this is published in the Public Store. If you're on 7.6, and load ASBRB, you can start my GSR window like this:

ASBReplicationUI open

There's a bug in the event handling for checkboxes in tables - you have to double click to set/reset them.

One word of warning to ASBAqua users however - this is a work-in-progress, and the current version of ASBAqua may have regressions.

After listening to the recent IM podcast where Randy Coulman was talking about FITnesse, I downloaded the software and had a look. I'll probably use it, but that's not really what this post is about.

The underlying implementation concept of FITnesse, where tables in a wiki are used as data for input into another process, got me thinking. I do the accounts for two contracting companies that my business partner and I run. Originally we used Quickbooks, but double entry accounting drives me crazy, so we switched to e-Record, which is a cash-accounting package supplied by the Australia Tax Office. Even so, it's still a PITA because there's no way to add notes to entries, particularly for non-obvious intercompany transactions or director asset puchases, and the interface is abysmal. Also it doesn't track Workcover or ASIC, and there's nowhere for links to sites or records phone conversations with the ATO etc etc. Finally, it just isn't clear to me what should be going on in the calculations, and I really, really hate not having a clear understanding of stuff like that. Hate it with a passion.

I'd done a preliminary pass at storing the records in XML and constructing the reports using XSLT, but that only solved the problem of understanding, not the additional stuff like providing annotated records for our accountant, nor does it keep me clear on what I've done. It's a lot like coding in that sense of coming back to something you've done and not understanding it.

Anyway, it should be obvious where I'm going with this. I've put my accounting records into Trac, simply because it's the wiki software I have installed for it's software development focus and svn/bzr integration. The records are represented as tables in pages - one or more records per table, multiple tables merged, table types by context or header row - which can be surrounded by prose descriptions, and links etc. I can organise stuff in different pages in whatever way makes it easier to understand. A simple bit of ST in VW to suck the pages and do any calculations required (or just validity checking), and Robert's your relative! I can even get VW to update pages, although that's a PITA in Trac because it has no API. Maybe Confluence would be better. Or an ST wiki, although that's maybe tighter coupling than I'd like. Obviously the code for interacting with an external wiki could be packaged to make this kind of stuff reusable. I tried VoodooPad, which I use for documentation, and although it will work for extraction, I'm not sure about the reverse. BTW, if you're on OSX I recommend both Acorn and FlySketch from the same company.

With appropriate extensible editing support in the wiki software, these embedded tables could be made richer, with metadata that doesn't normally show, annotated with some graphical indicator to control the visibility of the data. This would make this idea even more powerful - a combination of wiki prose with easily embedded data controls.

And moments after the idea of accounting records came up, I thought about literate programming in an ST context. I'm going to try putting some markers in wiki text that allow ST code/hierarchies etc to be automatically inserted/updated. This means I can write tutorials and documentation that includes ST inline, without having to copy and paste. The update process can also mark those insertion points that have changed relative to the existing version so I can see what needs updating as the code changes. I know it sounds like a hack - I'm ignoring e.g. versioning of the documentation - but it feels like a simple idea that won't be too hard to try. Very 80/20.

I've split the look experiments, which are primarily icons at this stage, out of ASBAqua package into ASBLook. Thus you can get the Aqua improvements on it's own.

As part of that process I've replace the bundle/package icons with ones more in keeping with the philosophy of the other icons, viz:

New version of ASBAqua, and this time a warning. This version contains a nearly compete set of aesthetically harmonized replacement icons for the RB, including class icons, and SUnitToo(ls). So if you hate the few icon changes I've made so far - yes, some people hate them :) - then stay away from this release, because it's a radical looking change. I'm going to split these changes off to a new package so you can just load the Aqua look enhancements without the general graphic mods that are currently included.

I've got a post in the works about the theory of these changes - and yes, there is a largely non-subjective rationale at work.

To whet your appetite, or turn your stomach completely inside out if you're not a fan, here's the obligatory screenshot: