S60 Open to new features

Adding support for UIQ to the Carbide.c++ UI designer posed some challeneges for our existing architecture. Perhaps the most challenging aspect was how to present the control collection to the user in a way that was both meaningful and useful and not overly cumbersome. Having decided to generate source code that would share control data using the control collection, we now had to find a way to present this to developers within the graphical editor.

First, I should probably explain a little about the control collection for those readers not well versed in UIQ UI programming. The control collection is basically an array of layout-agnostic control data for the controls that are used in different layouts corresponding to the same view. For each control, there is an entry with its shared data in the control collection. In each layout, the shared data for these controls is referenced through a unique id.

For any view, there may be multiple layouts defined for different UI configurations (e.g., softkeys, pen, portrait, landscape, etc.). In a given application, the same control may exist in different layouts corresponding to different UI configurations. Because UIQ uses layout managers, different UI configurations will often all use the same layout, but they can have different layouts as well depending on the design of the application. A text editor for collecting some kind of textual data from the user may exist in both softkey and pen configurations, and the maximum number of characters it accepts may be the same, even if it is laid out differently in the different UI configurations. The maximum length of the text editor control is an example of data that can be expressed in the control collection. In different layouts, each control in the control collection is augmented with layout-specific data (this data is the layout manager settings that are specific to how that control is laid out in that specific layout).

For each control the developer adds to a design, the UI designer tool had to present two different sets of data: shared data and layout-specific data. We had several design goals in mind. The shared data had to be presented so that it could be easily accessed irrespective of which layout the developer was editing. We didn't want to make the single layout use case more cumbersome in order to support the multiple layout case. First, we needed to present the controls in the control collection so that they could easily be added to new layouts while still allowing the developer to create brand new controls. And second, we needed to present the shared data for each control in a way that was easily accessible, rather than make the developer have to hunt down where to edit these values.

In the UI designer tool, we have various eclipse views working together. There is the main editor. This has a layout area where controls are rendered as they would look in the running application. In the editor, there is a palette of control creation tools arranged in drawers by type (e.g., editors like text or numeric editors, controls like labels and images, etc.). Controls can be added to a design from the palette by selecting them in the palette and clicking or dragging them on the layout area. Once an object is created, it also appears in the outline view, and when selected, its properties can be edited in the properties view. There are additional views as well, but these provide the main editing environment.

In the S60 UI designer, we had no data sharing requirements, objects are simply created from the palette and there is no shared data separate from layout-specific data. We decided that to separate the shared data from the layout-specific data, we would make two kinds of control types. One kind would allow editing the control-specific data and the other would be a generic control type with layout-specific data. This seemed ok, but we needed to tie these together. Our framework already contained the concept of one object containing a reference to another object through a special kind of property, and this seemed exactly the facility to use to tie the two objects together. For source generation, the reference property would be sufficient. Each layout control would have a reference to a control in the control collection. But this referencing facility would have to be really beefed up to allow us to make the visualization and editing as intuitive as it would need to be.

In my next blog entry, I will discuss some of the reference property enhancements and other new facilities we added to the UI designer framework to support our stated design goals in a general and reusable manner.