Customisations

16 February 2006 (Thursday)

When talking about playforge modules last year, we had an idea that XML-based ui definitions might be helpful. Some of us had had some experience with XUL/Mozilla – and saw the power. We thought initially, maybe we take some sort of existing framework and integrate it. However the more we’ve looked the more we come to believe that our requirements are slightly different to most of the XUL-like options out there.

Firstly, most of the XML-based java ui implentations are GUIbuilding IDE-like structures targetted at application developers who want to speed up their development path. They want and need all the power of swing – with many different options of control. While it’s great to give developers all the control they want – it’s also a burden. Our current feeling is that for playforge/sodaplay, it’s more appropriate to encourage simple well-designed xml-elements with a small number of configurable options, and instead allow people to create new xml-element definitions (which we’re calling widgets), which then define and produce their own components. A widget can thus be general purpose or very specific, but are quite likely to be a compound of several components (from a swing point of view) Furthermore, many of our components may be not swing at all, but rather AWT painted components.

Some specific widgets might be: (from sodaconstructor) the lefthand muscle sinewave, the right hand waveform widget, the central stage… But there may be new widgets that are more general purpose, although quite compound: a property inspector, a interpreted console for debugging and tweaking models. The sliders in sodaconstructor clearly are highly specific in their original classic form – and we’d really like to be able to offer “sodaconstructor classic” under playforge, but we also want to allow for a less concise and more understandable (and more accessible) interface than that as well.

The good news is that if we’re offering high-level widgets (understandable by non programmers, fingers crossed) then while perhaps not wanting to get into editing xml, a player of sodaconstructor might want to team up with a developer friend, or learn just enough xml, to be able to create their own tweaked version of the interface. Launching sodaconstructor with this tweaked interface shouldn’t change the behaviour of the model (the simulation) but it will change the user’s experience of it. As well as just copy and paste of xml, another option is to use a simple addition just to “remove” or replace a particular element.

See the entry on Bindings to see how we wire up the ui to the code.

As of mid Feb, the area we’re currently getting into trouble is with layout managers – managing to make these components to expand to their preferred size and make it natural and expected is a bit of a dark art. However at the moment we’re not trying to get things exactly right, instead, our focus this month is to get an end-to-end vision of the new sodaplay 2 prototyped up. The job after Febuary is to work on each of the playforge modules in turn to produce an “alpha” version of playforge ready for bleeding-edge experimentors to take it for a spin (alpha ready around June).

Advertisements
%d bloggers like this: