A Brand New Constructor

By Dave Mark, Metrowerks

This month’s Factory Floor interview is with Eric Scouten, Robin Mair, and Clint Popetz, three members of Metrowerks’ Constructor team. In case you’ve never used it before, Constructor is the visual front end that makes it easy to design interfaces for your Macintosh and Java applications and applets. With the release of CodeWarrior 10 in September, Constructor sports a new look and offers some new functionality. Read on to find out more.

Dave: How would you compare the old (CW8) and new (CW10) versions of Constructor?

Eric: There are now two Constructors: one for PowerPlant (MacOS) and one for Java. The Java Constructor debuted on CW10 and brings the same interface-building capabilities to the Java language framework (AWT) that we’ve been providing for our C++ framework for two years now.

In the PowerPlant Constructor, we’ve added several new resource editors since CW8. In CW9, we added the ability to edit menu bars. It’s pretty slick. The menu bar editor relies heavily on the Mac’s drag-and-drop interface. You can drag menu items around from one menu to another in a single mouse action. In CW10, we added support for many of the bitmap resource formats that people use in MacOS applications. You can edit icon suites, PICT resources, pattern resources, and more.

The other changes you’ll notice are not features, per se, but improvements in the user experience. In CW9, we began adopting the Apple Grayscale Appearance; this look is now almost complete in CW10, and is also visible in other parts of the CW product line (especially the IDE). Also, the CW8 Constructor had a lot of problems with stability. We’ve tightened up the code quality significantly since then.

Dave: Why are there two separate Constructors for Java (the AWT) and MacOS (for PowerPlant)?

Eric: There were two things that motivated this decision: code stability and code size. Constructor for Java contains a lot of new technology, such as an embedded copy of the Java virtual machine. This introduces some additional system requirements (such as the Code Fragment Manager for 68K) and adds quite a bit to the size of the final application. The Java runtime overhead is unnecessary in the Constructor for MacOS.

I also wanted to make sure that the development of Constructor for Java did not, in any way, disrupt the stability of the PowerPlant Constructor. Since the Java version was finalized fairly late in the CW10 release cycle, this was a significant concern.

In the future, both versions will be built from the same source files and will share about 80% common code. However, I expect that they will always remain separate. The project models are different, and the products will be growing in different directions.

Clint: As Eric said, embedding the Java runtime in Constructor creates a noticeable increase in memory footprint and binary size. We didn’t want to foist this on unsuspecting Constructor users. In addition, we felt that the intersection of Java programmers and PowerPlant programmers is pretty small at this point, so keeping the products separate seemed like a good move.

Dave: What is the Code Generation model for Java Constructor?

Eric: It’s pretty transparent, really. When you save a Constructor file, a Java source file is generated at the same time. It contains all the necessary code to rebuild the interface that you’ve described in the visual editor.

Clint: The code generation mechanism (which was written completely in Java) is meant to duplicate as closely as possible the UReanimator functionality in PowerPlant. So, the generated code consists of a series of classes, one for each component in the hierarchy, which know how to reanimate the target component. This source is not meant to be modified, since it is not the actual component subclass source. The developer can create their own Component subclasses in separate files, and then invoke the Reanimator methods to build the interface at runtime. Code to do this might look like:

MyFrame theFrame = (MyFrame)Reanimator.Reanimate(“MyFrame”,”theFrameName”);

In addition, the developer may wish to grab references to components in the newly created hierarchy. This functionality, which PowerPlant users will recognize as similar to the FindPaneByID functionality, is also provided by the Reanimator. Sample code to locate a TextArea in theFrame might look like:

TextArea theArea = (TextArea)Reanimator.Locate(“TextArea”,”theArea”,theFrame);

Dave: Over time, more and more resource editing appears to be moving into Constructor. Will Constructor eventually be able to take advantage of TMPLs? How much resource editing do you see moving into Constructor?

Eric: Right. Constructor began its life as a special-purpose resource editor, which knew about only the PowerPlant-specific resources (PPob and Txtr). We’ve gradually been adding more generic resource editing capabilities to it: menus, icons, etc.

These features are part of a long-term plan to evolve Constructor into a general-purpose resource editor and application builder. Editing resources described by TMPLs is an essential part of this plan, and it should be supported fairly soon (in either CW11 or CW12). We are also designing a plug-in API for resource editors, so you can write your own editors for custom resource types.

Dave: What Apple events does Constructor support now (in CW10)? What about new Apple events for future releases?

Eric: Apple event support in Constructor is pretty minimal. We’ve found that users view Constructor as an interactive program, and don’t typically want to script the process of designing a visual interface.

In the future, Constructor may have some Apple event interactions with the CodeWarrior IDE, to support building and running applications directly from Constructor.

Dave: Constructor allows you to design a CPPb resource that describes a “custom display class”, that is, a class derived from an existing PowerPlant display class. How does this mechanism work?

Eric: The properties (location, size, color, etc.) for each pane or view in a layout are stored in a bytestream. Constructor has built-in knowledge about all of the classes that are part of the PowerPlant framework itself.

Invariably, developers need to create their own subclasses of the PowerPlant building blocks to display the content that is specific to their application. (An example might be to create a subclass of LTableView that displays the list of message titles, senders, etc. in an e-mail application.)

The custom display class mechanism allows you to use Constructor to describe these specialized classes. If the class requires extra data to be in the bytestream, you create a CPPb resource to tell Constructor what these properties are. These properties then appear in the property inspector alongside the properties for the built-in class that you’ve derived from.

Custom display classes are due for a major overhaul in the next release of Constructor. We’ll be making the process quite a lot easier and less error-prone.

Dave: Products such as WebBurst allow you to build a complete applet or application using Constructor-like techniques, while Constructor has focused more on the specification of the user interface. Will Constructor be moving more into the application building model?

Robin: Constructor really started as a tool that provided easier access to the capabilities of PowerPlant and its pane/view mechanism, allowing graphical manipulation of the pane hierarchies. It is certainly our intent to move Constructor forward into the application building realm in an effort to make it easier for our customers to build applications. We will start moving in this direction by allowing the user to handle many of the more mundane aspects of application building directly from within Constructor. This would include providing tools for editing the standard resources such as, ‘BNDL’, ‘FREF’, etc. The inclusion of the new icon editor will also facilitate this by allowing the icons for the application to be created within Constructor. We don’t necessarily want to become the next ResEdit, but we want to enable our users to edit the resources commonly associated with building an application on the Mac.

In addition, we want to be able to provide a tighter integration between Constructor and the IDE in order to facilitate building an application without having to continually switch back and forth between the two environments. One of our goals in this direction is to allow the user to build the UI for their application, and get it up and running without having too write any code, so that they can quickly get something working.

Dave: WebBurst allows you to add graphic prettiness and animation to your applets in a way not currently supported by Constructor. Will Constructor be moving in this direction?

Robin: Many of these capabilities can be delivered by providing a richer set of objects that can be manipulated within Constructor. It is certainly one of our goals to provide a much richer set of objects that can be utilized in the construction of an application’s UI. Up until now we have been focusing on getting the core set of functionality in place. Once that task has been accomplished, we can start to provide richer capabilities that are not in the current versions of Constructor or PowerPlant.

We also are looking into mechanisms that will allow the user to introduce their custom classes into Constructor so that they have the ability to extend the set of capabilities that are available to them. CPPb’s currently allow you to do this but you cannot see how your classes would render, so the goal is provide a mechanism that would allow the drawing code from your classes to be available when your classes are included in a layout, thus allowing the visual manipulation to take on a more realistic representation than what is currently available in Constructor.

This mechanism could also potentially allow third party developers to create class libraries that could be used from within Constructor.

Dave: Does this mean that I’ll be able to import my own code into Constructor?

Robin: This has always been one of the thorny issues with Constructor, and any interface builder written with C++, for that matter.

Up until now we have had the CPPb mechanism which at least allows the user to setup the values they care about for their custom classes and to manipulate their layout, but the manipulation process has been a little unsatisfactory because their classes have only been represented in a layout as a rectangular box, which doesn’t exactly give you a feel for the appearance of the interface under construction.

The problem has been that with C++ there really is no clean way to get the users code included into Constructor, particularly the rendering aspects of the code, which is what you care about during the layout process.

In order to address this, Eric is working on a mechanism that would allow the users custom classes to handle the rendering of these classes within a layout, thereby making the layout process more visual than is currently available. We hope to make this available in a future version of Constructor in order to improve the layout process for custom classes.

As part of this effort we would also like to improve the CPPb mechanism so that it has greater flexibility, particularly in terms of the types that are available for constructing CPPbs.

Dave: What kind of changes do you see in future versions of Constructor?

Robin: Well as we’ve already mentioned, you can expect to see Constructor move more towards the application building realm, by allowing the user to perform many of the operations required to build an application directly from within Constructor. It is also our intent to establish a tighter integration with the IDE so that tasks, such as running or building the application, can be initiated from within Constructor.

We will also continue to develop the feature set of Constructor in order to deliver more power and flexibility to the application development process.

For example, we are planning on enhancing Constructor’s abilities to manage the various assets that come into play in the application building process. This basically can be viewed as a cataloging process that will provide the user with a centralized location for storing, browsing, and retrieving the various elements that are used to build both the UI for the application, as well as the application itself. This cataloging mechanism would be flexible enough to allow the user to drag elements from a catalog into a layout, or conversely to be able to drag a collection of elements from a layout back into the catalog for future reuse. The contents of the catalog would not be restricted to simple widgets, but would include all of the pieces needed in the construction process.

Another area we intend to improve is the inspection and editing of object properties, some of which you can get an early glimpse of by looking at the Java version of Constructor. This mechanism will be used in the PowerPlant version as well, and will be enhanced to provide a richer set of property editing capabilities.

As shown in the latest version of Constructor, with the inclusion of the icon editor, we want to continue delivering more of the resource editing capabilities that are needed in order to successfully construct an application.

We are definitely not standing still on Constructor. It is our goal to continue moving the tool forward in an effort to make it more powerful, flexible, and extensible. We also want to make it more accessible to novice users by continuing to improve its interface and the set of capabilities it delivers.

Clint: Since we are using live Java objects for displaying the interface, we plan to allow installation of user classes in Constructor, so that one could build interfaces with live instances of their classes. Along with this, we would like to provide a mechanism for added data in Constructor which could be streamed into user classes at runtime, similar to custom types in the PowerPlant Constructor.

Eric: The major directions for Constructor in the future are to take more of the gruntwork out of PowerPlant programming and to extend the resource-editing capabilities of the tool.

In the end, this is a tool to help users write great applications. Many of the features that you’ve seen implemented or planned are the direct result of user suggestions or comments. I invite people to contact me directly by e-mail (scouten@metrowerks.com) if they have new ideas that they’d like to see in future Constructors.