S60 Open to new features

In this next post about some of the enhancements we made to the Carbide.c++ UI designer framework to better support UIQ and specifically, the control collection, I will discuss how the linking between the layout-specific control data and the shared control data was achieved. Our main design goal was that the user not be bothered with the details. The worst thing we could have done with our design was to force the user to make this link manually.

Before I explain how we automated this, I'll start with some more background about how the UI designer framework is organized. The editor, as I explained in a previous post, consists of various views working together - the main editor view, the outline view, the properties view, events view, and more. It does not know anything about UIQ or S60. It only knows how to manipulate a design document consisting of objects in the model. These objects get their characteristics from libraries of components. Everything about UIQ or S60 or any other framework we may support in the future is defined in the components themselves, or through a few other extension points supported by the editor.

Components specify everything about how an object will behave in the editor and these are basically what the user sees in the palette. The palette consists of creation tools which are specified by those components that are compatible with the current design. Components are defined in xml and can point to various bits of code (java or javascript) to allow them to render themselves at designtime, layout their children, and implement many other interfaces supported by the editor. They also specify how they will generate c++ and rss source code.

Many enhancements to the designer framework take the form of additional interfaces that components can implement. So, to allow extended creation behavior we added command extenders. These allow a component to extend a command such as the command for creation of new objects from the palette. Extending the command allows the extended behavior to be atomic with the original behavior, so if the original behavior is undone, the extended behavior can also be undone.

The UIQ components do a lot of extending of commands, and specifically, the creation of extra objects and their linkage is achieved using this facility. But our design goal of making the sharing of controls in the control collection as simple as creating a completely new control required an additional enhancement.

Controls are created from the palette. When this happens, an object is added to the layout and another is added to the control collection. But to share an object from the control collection, the user would have to somehow select it in the control collection and make a new object the in another layout and link them together. This was too complex to do manually. The better solution would be that existing objects in the control collection should also appear in the palette. But the palette only consisted of components, not actual objects that had already been created.

An additional interface was added to allow an object to specify creation tools in the palette, along with their creation behavior. This would allow the control collection object to specify its children as creation tools in the palette. Here is a screenshot of the palette with a special drawer containing the objects in the control collection.

By simply creating them from the palette, controls in the control collection can be shared between layouts as easily as new controls can be created since they use the same semantics in the editor. The user does not need to know anything about how to achieve the linkage because the components specifying the controls extend the creation commands and link themselves automatically. Our design goals are met. Hopefully, the control collection is a little less daunting to novice UIQ programmers while still a familiar friend to the expert user.

In my last post I began discussing the challenges that the Carbide.c++ UI designer team faced in deciding how to present the control collection to the developer in a way that would make sense to experienced UIQ developers but that would not burden novice developers with too much detail. Specifically, I talked about how we needed to separate the shared layout-agnostic control data from the layout-specific data while still maintaining a unity between them so they could be edited as one and in the most obvious place.

I mentioned that we created two different kinds of control types, and linked them together with a property in the layout control object that referenced its shared control collection control object. However, we did not want to burden the developer with having to think about these as two separate objects in the designer, so we made some enhancements to the framework to facilitate that design goal.

Here is a screenshot of the outline view showing a multipage view with one layout. The layout has one page and its container contains a label control. The layout-specific control is the one in the container. It represents in the outline the control that is visible in the layout part of the main editor. The label control with the shared data is the one in the control collection and it is only visible in the outline. To make obvious that the layout control references the control in the control collection, we use a default naming convention that initially names the layout control using the string "ref" but we can't rely on the initial name to show how these are linked together because the user is free to change these names.

Instead, we added an enhancement to the UI designer component system that we called "reference property promotion." Using this facility, a layout control component can promote the properties of its referenced control in the control collection. This means that the referenced control's properties will be editable as if they are the layout control's own properties. So although the layout control only declares layout-specific properties (plus the reference property - "control" - that points to the control collection control with the shared data), the properties of the referenced control are editable as if they belonged directly to the the layout control. This way, the user would not need to hunt down the node in the outline to edit those properties. Here is what the properties view shows when focused on the layout control (label1Ref1). The layout-specific data is editable alongside the shared data. As you can see, the layout-specific properties represent a very small portion of the data available to be edited. Without the promotion, most of these properties would only be available if the user had selected the control in the control collection in the outline.

So reference property promotion was the enhancement we added to make the shared data easily accessible. In my next post I will discuss several enhancements we added to the UI designer framework to make the creation and linking of the layout and control collection controls transparent to the user, as well as making the sharing of control collection controls among multiple layouts as easy as creating new controls.

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.

UI Designer projects contain a set of files with the .uidesign extension. There's one for each screen in your application and there's always one called application.uidesign. This file drives the creation of the CAknApplication, CAknAppUi, and CAknDocument subclasses. It also has some settings that are common to all the screen designs.

I'm going to interrupt the tour of the S60 UI Designer features a bit to ask for some input on the next release. One priority for the next version will be filling in support all the commonly used S60 user interface elements. One of the things under consideration is support for multi-page forms and dialogs.

There's little question about the value of multi-page forms, as they give you another easy way to get the standard tabbing UI when all your pages are forms. Here's an example multi-page form from the S60 SDK documentation:

Multi-page dialogs are another matter. S60 applications typically use forms and settings lists when displaying multiple data items in a screen -- you don't really see the basic Symbian dialog used directly. So it's not clear that there are good use cases for multi-page dialogs. One might be where the dialog pages are things like a list box, or a single editor.

So let us know in the comments if you think multi-page dialogs are important. A description of your scenario, or a pointer to an existing application would help the most.

In a previous post we saw that the UI Designer wizard can help you create forms, setting item lists, and custom control containers. Those are the top-level designs it supports. Within a design there's a variety of notes and dialogs you can use.

This post gives a quick overview of the menu editor, including attaching your own code to run when the menu items are chosen.

As Markus previously wrote, we're near code freeze on Carbide.c++ 1.1. One of the major new features is the S60 UI Designer.

We had two key goals in mind when we started work on this tool. One was to help new developers quickly get started with S60 development. It's well known that Symbian and S60 development have a rather steep learning curve. Clearly, a graphical, drag and drop designer generating correct, efficient C++ and RSS can help.

The other goal was to help experienced S60 developers create user interface code more quickly, taking some of the drudgery out of day-to-day work. In addition to having an easy-to-use interface, developers told us that it was important that the generated source code be cleanly-designed, customizable, localizable, with support for features of the latest SDKs, such as scalable UI.

This is the first of a short series of posts introducing the UI designer and showing the features targeting these goals. Wel'll start with the wizard and graphical editor.