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.